1. 05 11月, 2014 7 次提交
  2. 05 10月, 2014 1 次提交
    • M
      block: disable entropy contributions for nonrot devices · b277da0a
      Mike Snitzer 提交于
      Clear QUEUE_FLAG_ADD_RANDOM in all block drivers that set
      QUEUE_FLAG_NONROT.
      
      Historically, all block devices have automatically made entropy
      contributions.  But as previously stated in commit e2e1a148 ("block: add
      sysfs knob for turning off disk entropy contributions"):
          - On SSD disks, the completion times aren't as random as they
            are for rotational drives. So it's questionable whether they
            should contribute to the random pool in the first place.
          - Calling add_disk_randomness() has a lot of overhead.
      
      There are more reliable sources for randomness than non-rotational block
      devices.  From a security perspective it is better to err on the side of
      caution than to allow entropy contributions from unreliable "random"
      sources.
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      b277da0a
  3. 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
  4. 04 6月, 2014 6 次提交
  5. 28 5月, 2014 1 次提交
  6. 10 5月, 2014 1 次提交
  7. 05 5月, 2014 6 次提交
  8. 11 4月, 2014 6 次提交
  9. 24 3月, 2014 5 次提交
  10. 14 3月, 2014 1 次提交
  11. 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
  12. 03 2月, 2014 1 次提交
  13. 30 1月, 2014 1 次提交
  14. 28 1月, 2014 2 次提交