1. 06 8月, 2015 3 次提交
  2. 05 8月, 2015 1 次提交
  3. 04 8月, 2015 5 次提交
  4. 25 7月, 2015 1 次提交
  5. 24 7月, 2015 1 次提交
  6. 23 7月, 2015 1 次提交
  7. 21 7月, 2015 1 次提交
  8. 19 7月, 2015 1 次提交
    • S
      hid-sensor: Fix suspend/resume delay · 88cc7b4e
      Srinivas Pandruvada 提交于
      By default all the sensors are runtime suspended state (lowest power
      state). During Linux suspend process, all the run time suspended
      devices are resumed and then suspended. This caused all sensors to
      power up and introduced delay in suspend time, when we introduced
      runtime PM for HID sensors. The opposite process happens during resume
      process.
      
      To fix this, we do powerup process of the sensors only when the request
      is issued from user (raw or tiggerred). In this way when runtime,
      resume calls for powerup it will simply return as this will not match
      user requested state.
      
      Note this is a regression fix as the increase in suspend / resume
      times can be substantial (report of 8 seconds on Len's laptop!)
      Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Tested-by: NLen Brown <len.brown@intel.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      88cc7b4e
  9. 18 7月, 2015 7 次提交
  10. 17 7月, 2015 1 次提交
  11. 16 7月, 2015 2 次提交
  12. 15 7月, 2015 5 次提交
  13. 13 7月, 2015 3 次提交
  14. 10 7月, 2015 5 次提交
    • P
      KVM: count number of assigned devices · 5544eb9b
      Paolo Bonzini 提交于
      If there are no assigned devices, the guest PAT are not providing
      any useful information and can be overridden to writeback; VMX
      always does this because it has the "IPAT" bit in its extended
      page table entries, but SVM does not have anything similar.
      Hook into VFIO and legacy device assignment so that they
      provide this information to KVM.
      Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>
      Tested-by: NJoerg Roedel <jroedel@suse.de>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      5544eb9b
    • E
      cdc_ncm: Add support for moving NDP to end of NCM frame · 4a0e3e98
      Enrico Mioso 提交于
      NCM specs are not actually mandating a specific position in the frame for
      the NDP (Network Datagram Pointer). However, some Huawei devices will
      ignore our aggregates if it is not placed after the datagrams it points
      to. Add support for doing just this, in a per-device configurable way.
      While at it, update NCM subdrivers, disabling this functionality in all of
      them, except in huawei_cdc_ncm where it is enabled instead.
      We aren't making any distinction between different Huawei NCM devices,
      based on what the vendor driver does. Standard NCM devices are left
      unaffected: if they are compliant, they should be always usable, still
      stay on the safe side.
      
      This change has been tested and working with a Huawei E3131 device (which
      works regardless of NDP position), a Huawei E3531 (also working both
      ways) and an E3372 (which mandates NDP to be after indexed datagrams).
      
      V1->V2:
      - corrected wrong NDP acronym definition
      - fixed possible NULL pointer dereference
      - patch cleanup
      V2->V3:
      - Properly account for the NDP size when writing new packets to SKB
      Signed-off-by: NEnrico Mioso <mrkiko.rs@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a0e3e98
    • T
      blkcg: fix blkcg_policy_data allocation bug · 06b285bd
      Tejun Heo 提交于
      e48453c3 ("block, cgroup: implement policy-specific per-blkcg
      data") updated per-blkcg policy data to be dynamically allocated.
      When a policy is registered, its policy data aren't created.  Instead,
      when the policy is activated on a queue, the policy data are allocated
      if there are blkg's (blkcg_gq's) which are attached to a given blkcg.
      This is buggy.  Consider the following scenario.
      
      1. A blkcg is created.  No blkg's attached yet.
      
      2. The policy is registered.  No policy data is allocated.
      
      3. The policy is activated on a queue.  As the above blkcg doesn't
         have any blkg's, it won't allocate the matching blkcg_policy_data.
      
      4. An IO is issued from the blkcg and blkg is created and the blkcg
         still doesn't have the matching policy data allocated.
      
      With cfq-iosched, this leads to an oops.
      
      It also doesn't free policy data on policy unregistration assuming
      that freeing of all policy data on blkcg destruction should take care
      of it; however, this also is incorrect.
      
      1. A blkcg has policy data.
      
      2. The policy gets unregistered but the policy data remains.
      
      3. Another policy gets registered on the same slot.
      
      4. Later, the new policy tries to allocate policy data on the previous
         blkcg but the slot is already occupied and gets skipped.  The
         policy ends up operating on the policy data of the previous policy.
      
      There's no reason to manage blkcg_policy_data lazily.  The reason we
      do lazy allocation of blkg's is that the number of all possible blkg's
      is the product of cgroups and block devices which can reach a
      surprising level.  blkcg_policy_data is contrained by the number of
      cgroups and shouldn't be a problem.
      
      This patch makes blkcg_policy_data to be allocated for all existing
      blkcg's on policy registration and freed on unregistration and removes
      blkcg_policy_data handling from policy [de]activation paths.  This
      makes that blkcg_policy_data are created and removed with the policy
      they belong to and fixes the above described problems.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Fixes: e48453c3 ("block, cgroup: implement policy-specific per-blkcg data")
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Arianna Avanzini <avanzini.arianna@gmail.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      06b285bd
    • T
      blkcg: implement all_blkcgs list · 7876f930
      Tejun Heo 提交于
      Add all_blkcgs list goes through blkcg->all_blkcgs_node and is
      protected by blkcg_pol_mutex.  This will be used to fix
      blkcg_policy_data allocation bug.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Arianna Avanzini <avanzini.arianna@gmail.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      7876f930
    • I
      libceph: enable ceph in a non-default network namespace · 757856d2
      Ilya Dryomov 提交于
      Grab a reference on a network namespace of the 'rbd map' (in case of
      rbd) or 'mount' (in case of ceph) process and use that to open sockets
      instead of always using init_net and bailing if network namespace is
      anything but init_net.  Be careful to not share struct ceph_client
      instances between different namespaces and don't add any code in the
      !CONFIG_NET_NS case.
      
      This is based on a patch from Hong Zhiguo <zhiguohong@tencent.com>.
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: NSage Weil <sage@redhat.com>
      757856d2
  15. 09 7月, 2015 2 次提交
  16. 08 7月, 2015 1 次提交
    • T
      hotplug: Prevent alloc/free of irq descriptors during cpu up/down · a8994181
      Thomas Gleixner 提交于
      When a cpu goes up some architectures (e.g. x86) have to walk the irq
      space to set up the vector space for the cpu. While this needs extra
      protection at the architecture level we can avoid a few race
      conditions by preventing the concurrent allocation/free of irq
      descriptors and the associated data.
      
      When a cpu goes down it moves the interrupts which are targeted to
      this cpu away by reassigning the affinities. While this happens
      interrupts can be allocated and freed, which opens a can of race
      conditions in the code which reassignes the affinities because
      interrupt descriptors might be freed underneath.
      
      Example:
      
      CPU1				CPU2
      cpu_up/down
       irq_desc = irq_to_desc(irq);
      				remove_from_radix_tree(desc);
       raw_spin_lock(&desc->lock);
      				free(desc);
      
      We could protect the irq descriptors with RCU, but that would require
      a full tree change of all accesses to interrupt descriptors. But
      fortunately these kind of race conditions are rather limited to a few
      things like cpu hotplug. The normal setup/teardown is very well
      serialized. So the simpler and obvious solution is:
      
      Prevent allocation and freeing of interrupt descriptors accross cpu
      hotplug.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: xiao jin <jin.xiao@intel.com>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com>
      Link: http://lkml.kernel.org/r/20150705171102.063519515@linutronix.de
      a8994181