1. 05 11月, 2014 2 次提交
  2. 13 6月, 2014 1 次提交
    • K
      NVMe: Fix hot cpu notification dead lock · f3db22fe
      Keith Busch 提交于
      There is a potential dead lock if a cpu event occurs during nvme probe
      since it registered with hot cpu notification. This fixes the race by
      having the module register with notification outside of probe rather
      than have each device register.
      
      The actual work is done in a scheduled work queue instead of in the
      notifier since assigning IO queues has the potential to block if the
      driver creates additional queues.
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      Signed-off-by: NMatthew Wilcox <matthew.r.wilcox@intel.com>
      f3db22fe
  3. 04 6月, 2014 1 次提交
  4. 05 5月, 2014 3 次提交
  5. 11 4月, 2014 4 次提交
  6. 24 3月, 2014 2 次提交
    • K
      NVMe: IOCTL path RCU protect queue access · 4f5099af
      Keith Busch 提交于
      This adds rcu protected access to a queue in the nvme IOCTL path
      to fix potential races between a surprise removal and queue usage in
      nvme_submit_sync_cmd. The fix holds the rcu_read_lock() here to prevent
      the nvme_queue from freeing while this path is executing so it can't
      sleep, and so this path will no longer wait for a available command
      id should they all be in use at the time a passthrough IOCTL request
      is received.
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      Signed-off-by: NMatthew Wilcox <matthew.r.wilcox@intel.com>
      4f5099af
    • K
      NVMe: RCU protected access to io queues · 5a92e700
      Keith Busch 提交于
      This adds rcu protected access to nvme_queue to fix a race between a
      surprise removal freeing the queue and a thread with open reference on
      a NVMe block device using that queue.
      
      The queues do not need to be rcu protected during the initialization or
      shutdown parts, so I've added a helper function for raw deferencing
      to get around the sparse errors.
      
      There is still a hole in the IOCTL path for the same problem, which is
      fixed in a subsequent patch.
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      Signed-off-by: NMatthew Wilcox <matthew.r.wilcox@intel.com>
      5a92e700
  7. 07 3月, 2014 1 次提交
    • T
      nvme: don't use PREPARE_WORK · 9ca97374
      Tejun Heo 提交于
      PREPARE_[DELAYED_]WORK() are being phased out.  They have few users
      and a nasty surprise in terms of reentrancy guarantee as workqueue
      considers work items to be different if they don't have the same work
      function.
      
      nvme_dev->reset_work is multiplexed with multiple work functions.
      Introduce nvme_reset_workfn() which invokes nvme_dev->reset_workfn and
      always use it as the work function and update the users to set the
      ->reset_workfn field instead of overriding the work function using
      PREPARE_WORK().
      
      It would probably be best to route this with other related updates
      through the workqueue tree.
      
      Compile tested.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Matthew Wilcox <willy@linux.intel.com>
      Cc: linux-nvme@lists.infradead.org
      9ca97374
  8. 28 1月, 2014 2 次提交
  9. 17 12月, 2013 2 次提交
  10. 19 11月, 2013 1 次提交
  11. 04 9月, 2013 3 次提交
  12. 21 6月, 2013 1 次提交
  13. 08 5月, 2013 1 次提交
  14. 03 5月, 2013 2 次提交
  15. 17 4月, 2013 3 次提交
  16. 29 3月, 2013 1 次提交
  17. 27 3月, 2013 3 次提交
  18. 13 11月, 2012 1 次提交
  19. 28 7月, 2012 1 次提交
  20. 27 7月, 2012 1 次提交
  21. 05 11月, 2011 4 次提交