1. 17 8月, 2017 1 次提交
  2. 28 6月, 2017 1 次提交
  3. 13 6月, 2017 1 次提交
  4. 09 5月, 2017 1 次提交
  5. 01 2月, 2017 1 次提交
  6. 28 1月, 2017 4 次提交
  7. 06 11月, 2016 1 次提交
    • J
      block: add code to track actual device queue depth · d278d4a8
      Jens Axboe 提交于
      For blk-mq, ->nr_requests does track queue depth, at least at init
      time. But for the older queue paths, it's simply a soft setting.
      On top of that, it's generally larger than the hardware setting
      on purpose, to allow backup of requests for merging.
      
      Fill a hole in struct request with a 'queue_depth' member, that
      drivers can call to more closely inform the block layer of the
      real queue depth.
      Signed-off-by: NJens Axboe <axboe@fb.com>
      Reviewed-by: NJan Kara <jack@suse.cz>
      d278d4a8
  8. 27 9月, 2016 1 次提交
    • B
      scsi: Avoid that toggling use_blk_mq triggers a memory leak · 8d58881b
      Bart Van Assche 提交于
      This patch avoids that the following memory leak is triggered if
      use_blk_mq is disabled after a SCSI host has been allocated by the
      ib_srp driver and before the same SCSI host is freed:
      
      unreferenced object 0xffff8803a168c568 (size 256):
        backtrace:
          [<ffffffff81620c95>] kmemleak_alloc+0x45/0xa0
          [<ffffffff811bb104>] __kmalloc_node+0x1e4/0x400
          [<ffffffff81309fe4>] blk_mq_alloc_tag_set+0xb4/0x230
          [<ffffffff814731b7>] scsi_mq_setup_tags+0xc7/0xd0
          [<ffffffff81469c26>] scsi_add_host_with_dma+0x216/0x2d0
          [<ffffffffa064bef5>] srp_create_target+0xe55/0x13d0 [ib_srp]
          [<ffffffff8143ce23>] dev_attr_store+0x13/0x20
          [<ffffffff8125f030>] sysfs_kf_write+0x40/0x50
          [<ffffffff8125e397>] kernfs_fop_write+0x137/0x1c0
          [<ffffffff811d8c13>] __vfs_write+0x23/0x140
          [<ffffffff811d92e0>] vfs_write+0xb0/0x190
          [<ffffffff811da5b4>] SyS_write+0x44/0xa0
          [<ffffffff8162c8a5>] entry_SYSCALL_64_fastpath+0x18/0xa8
      
      Fixes: 9aa9cc42 ("scsi: remove the disable_blk_mq host flag")
      Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Cc: <stable@vger.kernel.org>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      8d58881b
  9. 16 7月, 2016 1 次提交
  10. 05 4月, 2016 1 次提交
  11. 01 12月, 2015 1 次提交
  12. 10 11月, 2015 1 次提交
  13. 01 6月, 2015 1 次提交
  14. 19 3月, 2015 1 次提交
  15. 23 1月, 2015 1 次提交
    • R
      scsi: always increment reference count · dc4515ea
      Rusty Russell 提交于
      James reported:
      > After e513cc1c module: Remove stop_machine from module unloading,
      > module_refcount() is returning (unsigned long)-1 when called from within
      > a routine that runs in module_exit.  This is confusing the scsi device
      > put code which is coded to detect a module_refcount() of zero for
      > running within a module exit routine and not try to do another
      > module_put.  The fix is to restore the original behaviour of
      > module_refcount() and return zero if we're running inside an exit
      > routine.
      
      The correct fix is to turn try_module_get() into __module_get(), and
      always do the module_put().
      Acked-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      dc4515ea
  16. 09 1月, 2015 2 次提交
  17. 04 12月, 2014 2 次提交
  18. 25 11月, 2014 1 次提交
  19. 24 11月, 2014 1 次提交
  20. 12 11月, 2014 6 次提交
  21. 01 10月, 2014 1 次提交
  22. 16 9月, 2014 1 次提交
    • A
      scsi: don't store LUN bits in CDB[1] for USB mass-storage devices · 50c4e964
      Alan Stern 提交于
      The SCSI specification requires that the second Command Data Byte
      should contain the LUN value in its high-order bits if the recipient
      device reports SCSI level 2 or below.  Nevertheless, some USB
      mass-storage devices use those bits for other purposes in
      vendor-specific commands.  Currently Linux has no way to send such
      commands, because the SCSI stack always overwrites the LUN bits.
      
      Testing shows that Windows 7 and XP do not store the LUN bits in the
      CDB when sending commands to a USB device.  This doesn't matter if the
      device uses the Bulk-Only or UAS transports (which virtually all
      modern USB mass-storage devices do), as these have a separate
      mechanism for sending the LUN value.
      
      Therefore this patch introduces a flag in the Scsi_Host structure to
      inform the SCSI midlayer that a transport does not require the LUN
      bits to be stored in the CDB, and it makes usb-storage set this flag
      for all devices using the Bulk-Only transport.  (UAS is handled by a
      separate driver, but it doesn't really matter because no SCSI-2 or
      lower device is at all likely to use UAS.)
      
      The patch also cleans up the code responsible for storing the LUN
      value by adding a bitflag to the scsi_device structure.  The test for
      whether to stick the LUN value in the CDB can be made when the device
      is probed, and stored for future use rather than being made over and
      over in the fast path.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NTiziano Bacocco <tiziano.bacocco@gmail.com>
      Acked-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Acked-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      50c4e964
  23. 16 8月, 2014 1 次提交
  24. 29 7月, 2014 1 次提交
  25. 26 7月, 2014 3 次提交
    • C
      scsi: update scsi_device_types · c6e4f191
      Christoph Hellwig 提交于
      Add two new device types, most importantly the zoned block device
      one.
      
      Split from an earlier patch by Hannes Reinecke.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NHannes Reinecke <hare@suse.de>
      Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
      c6e4f191
    • C
      scsi: add support for a blk-mq based I/O path. · d285203c
      Christoph Hellwig 提交于
      This patch adds support for an alternate I/O path in the scsi midlayer
      which uses the blk-mq infrastructure instead of the legacy request code.
      
      Use of blk-mq is fully transparent to drivers, although for now a host
      template field is provided to opt out of blk-mq usage in case any unforseen
      incompatibilities arise.
      
      In general replacing the legacy request code with blk-mq is a simple and
      mostly mechanical transformation.  The biggest exception is the new code
      that deals with the fact the I/O submissions in blk-mq must happen from
      process context, which slightly complicates the I/O completion handler.
      The second biggest differences is that blk-mq is build around the concept
      of preallocated requests that also include driver specific data, which
      in SCSI context means the scsi_cmnd structure.  This completely avoids
      dynamic memory allocations for the fast path through I/O submission.
      
      Due the preallocated requests the MQ code path exclusively uses the
      host-wide shared tag allocator instead of a per-LUN one.  This only
      affects drivers actually using the block layer provided tag allocator
      instead of their own.  Unlike the old path blk-mq always provides a tag,
      although drivers don't have to use it.
      
      For now the blk-mq path is disable by defauly and must be enabled using
      the "use_blk_mq" module parameter.  Once the remaining work in the block
      layer to make blk-mq more suitable for slow devices is complete I hope
      to make it the default and eventually even remove the old code path.
      
      Based on the earlier scsi-mq prototype by Nicholas Bellinger.
      
      Thanks to Bart Van Assche and Robert Elliot for testing, benchmarking and
      various sugestions and code contributions.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Reviewed-by: NHannes Reinecke <hare@suse.de>
      Reviewed-by: NWebb Scales <webbnh@hp.com>
      Acked-by: NJens Axboe <axboe@kernel.dk>
      Tested-by: NBart Van Assche <bvanassche@acm.org>
      Tested-by: NRobert Elliott <elliott@hp.com>
      d285203c
    • C
      scsi: fix the {host,target,device}_blocked counter mess · cd9070c9
      Christoph Hellwig 提交于
      Seems like these counters are missing any sort of synchronization for
      updates, as a over 10 year old comment from me noted.  Fix this by
      using atomic counters, and while we're at it also make sure they are
      in the same cacheline as the _busy counters and not needlessly stored
      to in every I/O completion.
      
      With the new model the _busy counters can temporarily go negative,
      so all the readers are updated to check for > 0 values.  Longer
      term every successful I/O completion will reset the counters to zero,
      so the temporarily negative values will not cause any harm.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Reviewed-by: NWebb Scales <webbnh@hp.com>
      Acked-by: NJens Axboe <axboe@kernel.dk>
      Tested-by: NBart Van Assche <bvanassche@acm.org>
      Tested-by: NRobert Elliott <elliott@hp.com>
      cd9070c9
  26. 25 7月, 2014 3 次提交