1. 02 9月, 2020 1 次提交
  2. 21 11月, 2019 1 次提交
  3. 05 10月, 2019 1 次提交
    • M
      scsi: implement .cleanup_rq callback · e94443fc
      Ming Lei 提交于
      [ Upstream commit b7e9e1fb7a9227be34ad4a5e778022c3164494cf ]
      
      Implement .cleanup_rq() callback for freeing driver private part
      of the request. Then we can avoid to leak this part if the request isn't
      completed by SCSI, and freed by blk-mq or upper layer(such as dm-rq) finally.
      
      Cc: Ewan D. Milne <emilne@redhat.com>
      Cc: Bart Van Assche <bvanassche@acm.org>
      Cc: Hannes Reinecke <hare@suse.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Mike Snitzer <snitzer@redhat.com>
      Cc: dm-devel@redhat.com
      Cc: <stable@vger.kernel.org>
      Fixes: 396eaf21 ("blk-mq: improve DM's blk-mq IO merging via blk_insert_cloned_request feedback")
      Signed-off-by: NMing Lei <ming.lei@redhat.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e94443fc
  4. 04 8月, 2019 2 次提交
    • B
      scsi: core: Avoid that a kernel warning appears during system resume · 475f7781
      Bart Van Assche 提交于
      commit 17605afaae825b0291f80c62a7f6565879edaa8a upstream.
      
      Since scsi_device_quiesce() skips SCSI devices that have another state than
      RUNNING, OFFLINE or TRANSPORT_OFFLINE, scsi_device_resume() should not
      complain about SCSI devices that have been skipped. Hence this patch.  This
      patch avoids that the following warning appears during resume:
      
      WARNING: CPU: 3 PID: 1039 at blk_clear_pm_only+0x2a/0x30
      CPU: 3 PID: 1039 Comm: kworker/u8:49 Not tainted 5.0.0+ #1
      Hardware name: LENOVO 4180F42/4180F42, BIOS 83ET75WW (1.45 ) 05/10/2013
      Workqueue: events_unbound async_run_entry_fn
      RIP: 0010:blk_clear_pm_only+0x2a/0x30
      Call Trace:
       ? scsi_device_resume+0x28/0x50
       ? scsi_dev_type_resume+0x2b/0x80
       ? async_run_entry_fn+0x2c/0xd0
       ? process_one_work+0x1f0/0x3f0
       ? worker_thread+0x28/0x3c0
       ? process_one_work+0x3f0/0x3f0
       ? kthread+0x10c/0x130
       ? __kthread_create_on_node+0x150/0x150
       ? ret_from_fork+0x1f/0x30
      
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Hannes Reinecke <hare@suse.com>
      Cc: Ming Lei <ming.lei@redhat.com>
      Cc: Johannes Thumshirn <jthumshirn@suse.de>
      Cc: Oleksandr Natalenko <oleksandr@natalenko.name>
      Cc: Martin Steigerwald <martin@lichtvoll.de>
      Cc: <stable@vger.kernel.org>
      Reported-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
      Tested-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
      Fixes: 3a0a5299 ("block, scsi: Make SCSI quiesce and resume work reliably") # v4.15
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      475f7781
    • B
      block, scsi: Change the preempt-only flag into a counter · c58a6507
      Bart Van Assche 提交于
      commit cd84a62e0078dce09f4ed349bec84f86c9d54b30 upstream.
      
      The RQF_PREEMPT flag is used for three purposes:
      - In the SCSI core, for making sure that power management requests
        are executed even if a device is in the "quiesced" state.
      - For domain validation by SCSI drivers that use the parallel port.
      - In the IDE driver, for IDE preempt requests.
      Rename "preempt-only" into "pm-only" because the primary purpose of
      this mode is power management. Since the power management core may
      but does not have to resume a runtime suspended device before
      performing system-wide suspend and since a later patch will set
      "pm-only" mode as long as a block device is runtime suspended, make
      it possible to set "pm-only" mode from more than one context. Since
      with this change scsi_device_quiesce() is no longer idempotent, make
      that function return early if it is called for a quiesced queue.
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Acked-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Reviewed-by: NHannes Reinecke <hare@suse.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NMing Lei <ming.lei@redhat.com>
      Cc: Jianchao Wang <jianchao.w.wang@oracle.com>
      Cc: Johannes Thumshirn <jthumshirn@suse.de>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c58a6507
  5. 26 7月, 2019 1 次提交
  6. 27 4月, 2019 1 次提交
  7. 20 4月, 2019 1 次提交
    • B
      scsi: core: Avoid that system resume triggers a kernel warning · 29b934dd
      Bart Van Assche 提交于
      [ Upstream commit 388b4e6a00bb3097278ed1648ac5a1cb48c894e6 ]
      
      scsi_device_quiesce() and scsi_device_resume() are called during
      system-wide suspend and resume. scsi_device_quiesce() only succeeds for
      SCSI devices that are in one of the RUNNING, OFFLINE or TRANSPORT_OFFLINE
      states (see also scsi_set_device_state()).  This patch avoids that the
      following warning is triggered when resuming a system for which quiescing a
      SCSI device failed:
      
      WARNING: CPU: 2 PID: 11303 at drivers/scsi/scsi_lib.c:2600 scsi_device_resume+0x4f/0x58
      CPU: 2 PID: 11303 Comm: kworker/u8:70 Not tainted 5.0.0-rc1+ #50
      Hardware name: LENOVO 80E3/Lancer 5B2, BIOS A2CN45WW(V2.13) 08/04/2016
      Workqueue: events_unbound async_run_entry_fn
      Call Trace:
       scsi_dev_type_resume+0x2e/0x60
       async_run_entry_fn+0x32/0xd8
       process_one_work+0x1f4/0x420
       worker_thread+0x28/0x3c0
       kthread+0x118/0x130
       ret_from_fork+0x22/0x40
      
      Cc: Przemek Socha <soprwa@gmail.com>
      Reported-by: NPrzemek Socha <soprwa@gmail.com>
      Fixes: 3a0a5299 ("block, scsi: Make SCSI quiesce and resume work reliably") # v4.15
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      29b934dd
  8. 10 3月, 2019 1 次提交
  9. 21 11月, 2018 1 次提交
    • M
      SCSI: fix queue cleanup race before queue initialization is done · 410306a0
      Ming Lei 提交于
      commit 8dc765d438f1e42b3e8227b3b09fad7d73f4ec9a upstream.
      
      c2856ae2 ("blk-mq: quiesce queue before freeing queue") has
      already fixed this race, however the implied synchronize_rcu()
      in blk_mq_quiesce_queue() can slow down LUN probe a lot, so caused
      performance regression.
      
      Then 1311326c ("blk-mq: avoid to synchronize rcu inside blk_cleanup_queue()")
      tried to quiesce queue for avoiding unnecessary synchronize_rcu()
      only when queue initialization is done, because it is usual to see
      lots of inexistent LUNs which need to be probed.
      
      However, turns out it isn't safe to quiesce queue only when queue
      initialization is done. Because when one SCSI command is completed,
      the user of sending command can be waken up immediately, then the
      scsi device may be removed, meantime the run queue in scsi_end_request()
      is still in-progress, so kernel panic can be caused.
      
      In Red Hat QE lab, there are several reports about this kind of kernel
      panic triggered during kernel booting.
      
      This patch tries to address the issue by grabing one queue usage
      counter during freeing one request and the following run queue.
      
      Fixes: 1311326c ("blk-mq: avoid to synchronize rcu inside blk_cleanup_queue()")
      Cc: Andrew Jones <drjones@redhat.com>
      Cc: Bart Van Assche <bart.vanassche@wdc.com>
      Cc: linux-scsi@vger.kernel.org
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
      Cc: stable <stable@vger.kernel.org>
      Cc: jianchao.wang <jianchao.w.wang@oracle.com>
      Signed-off-by: NMing Lei <ming.lei@redhat.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      410306a0
  10. 28 8月, 2018 2 次提交
    • M
      Revert "scsi: core: avoid host-wide host_busy counter for scsi_mq" · d772a65d
      Ming Lei 提交于
      This reverts commit 32872863.
      
      There is fundamental issue in commit 32872863 (scsi: core: avoid
      host-wide host_busy counter for scsi_mq) because SCSI's host busy counter
      may not be same with counter of blk-mq's inflight tags, especially in case
      of none io scheduler.
      
      We may switch to other approach for addressing this scsi_mq's performance
      issue, such as percpu counter or kind of ways, so revert this commit first
      for fixing this kind of issue in EH path, as reported by Jens.
      
      Cc: Omar Sandoval <osandov@fb.com>,
      Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
      Cc: James Bottomley <james.bottomley@hansenpartnership.com>,
      Cc: Christoph Hellwig <hch@lst.de>,
      Cc: Don Brace <don.brace@microsemi.com>
      Cc: Kashyap Desai <kashyap.desai@broadcom.com>
      Cc: Mike Snitzer <snitzer@redhat.com>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Laurence Oberman <loberman@redhat.com>
      Cc: Bart Van Assche <bart.vanassche@wdc.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Reported-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NMing Lei <ming.lei@redhat.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      d772a65d
    • M
      Revert "scsi: core: fix scsi_host_queue_ready" · 23aa8e69
      Ming Lei 提交于
      This reverts commit 265d59aa.
      
      There is fundamental issue in commit 32872863 (scsi: core: avoid
      host-wide host_busy counter for scsi_mq) because SCSI's host busy counter
      may not be same with counter of blk-mq's inflight tags, especially in case
      of none io scheduler.
      
      So revert this commit first.
      
      Cc: Omar Sandoval <osandov@fb.com>,
      Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
      Cc: James Bottomley <james.bottomley@hansenpartnership.com>,
      Cc: Christoph Hellwig <hch@lst.de>,
      Cc: Don Brace <don.brace@microsemi.com>
      Cc: Kashyap Desai <kashyap.desai@broadcom.com>
      Cc: Mike Snitzer <snitzer@redhat.com>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Laurence Oberman <loberman@redhat.com>
      Cc: Bart Van Assche <bart.vanassche@wdc.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Jens Axboe <axboe@kernel.dk>
      Reported-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NMing Lei <ming.lei@redhat.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      23aa8e69
  11. 09 8月, 2018 1 次提交
  12. 03 8月, 2018 1 次提交
    • K
      scsi: Check sense buffer size at build time · 704f8392
      Kees Cook 提交于
      To avoid introducing problems like those fixed in commit f7068114
      ("sr: pass down correctly sized SCSI sense buffer"), this creates a macro
      wrapper for scsi_execute() that verifies the size of the sense buffer
      similar to what was done for command string sizes in commit 3756f640
      ("exec: avoid gcc-8 warning for get_task_comm").
      
      Another solution could be to add a length argument to scsi_execute(),
      but this function already takes a lot of arguments and Jens was not fond
      of that approach.
      
      Additionally, this moves the SCSI_SENSE_BUFFERSIZE definition into
      scsi_device.h, and removes a redundant include for scsi_device.h from
      scsi_cmnd.h.
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      704f8392
  13. 03 7月, 2018 1 次提交
    • M
      scsi: core: fix scsi_host_queue_ready · 265d59aa
      Ming Lei 提交于
      32872863 ("scsi: avoid to hold host-wide counter of host_busy for
      scsi_mq") adds one extra check on scsi_host_busy(shost) in
      scsi_host_queue_ready(), which is wrong and not necessary, can causes
      booting stall on LSI53c895A.
      
      So remove the check.
      
      Cc: Omar Sandoval <osandov@fb.com>,
      Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
      Cc: James Bottomley <james.bottomley@hansenpartnership.com>,
      Cc: Christoph Hellwig <hch@lst.de>,
      Cc: Don Brace <don.brace@microsemi.com>
      Cc: Kashyap Desai <kashyap.desai@broadcom.com>
      Cc: Mike Snitzer <snitzer@redhat.com>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Laurence Oberman <loberman@redhat.com>
      Cc: Bart Van Assche <bart.vanassche@wdc.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Reported-by: NGuenter Roeck <linux@roeck-us.net>
      Fixes: 32872863 ("scsi: avoid to hold host-wide counter of host_busy for scsi_mq")
      Signed-off-by: NMing Lei <ming.lei@redhat.com>
      Tested-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      265d59aa
  14. 27 6月, 2018 9 次提交
  15. 29 5月, 2018 1 次提交
  16. 14 5月, 2018 2 次提交
  17. 07 5月, 2018 1 次提交
  18. 10 4月, 2018 3 次提交
  19. 14 3月, 2018 1 次提交
    • C
      bsg: split handling of SCSI CDBs vs transport requeues · 17cb960f
      Christoph Hellwig 提交于
      The current BSG design tries to shoe-horn the transport-specific
      passthrough commands into the overall framework for SCSI passthrough
      requests.  This has a couple problems:
      
       - each passthrough queue has to set the QUEUE_FLAG_SCSI_PASSTHROUGH flag
         despite not dealing with SCSI commands at all.  Because of that these
         queues could also incorrectly accept SCSI commands from in-kernel
         users or through the legacy SCSI_IOCTL_SEND_COMMAND ioctl.
       - the real SCSI bsg queues also incorrectly accept bsg requests of the
         BSG_SUB_PROTOCOL_SCSI_TRANSPORT type
       - the bsg transport code is almost unredable because it tries to reuse
         different SCSI concepts for its own purpose.
      
      This patch instead adds a new bsg_ops structure to handle the two cases
      differently, and thus solves all of the above problems.  Another side
      effect is that the bsg-lib queues also don't need to embedd a
      struct scsi_request anymore.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NHannes Reinecke <hare@suse.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      17cb960f
  20. 13 3月, 2018 1 次提交
  21. 09 3月, 2018 1 次提交
  22. 07 3月, 2018 1 次提交
  23. 02 3月, 2018 2 次提交
  24. 01 3月, 2018 1 次提交
  25. 14 2月, 2018 1 次提交
  26. 31 1月, 2018 1 次提交
    • M
      blk-mq: introduce BLK_STS_DEV_RESOURCE · 86ff7c2a
      Ming Lei 提交于
      This status is returned from driver to block layer if device related
      resource is unavailable, but driver can guarantee that IO dispatch
      will be triggered in future when the resource is available.
      
      Convert some drivers to return BLK_STS_DEV_RESOURCE.  Also, if driver
      returns BLK_STS_RESOURCE and SCHED_RESTART is set, rerun queue after
      a delay (BLK_MQ_DELAY_QUEUE) to avoid IO stalls.  BLK_MQ_DELAY_QUEUE is
      3 ms because both scsi-mq and nvmefc are using that magic value.
      
      If a driver can make sure there is in-flight IO, it is safe to return
      BLK_STS_DEV_RESOURCE because:
      
      1) If all in-flight IOs complete before examining SCHED_RESTART in
      blk_mq_dispatch_rq_list(), SCHED_RESTART must be cleared, so queue
      is run immediately in this case by blk_mq_dispatch_rq_list();
      
      2) if there is any in-flight IO after/when examining SCHED_RESTART
      in blk_mq_dispatch_rq_list():
      - if SCHED_RESTART isn't set, queue is run immediately as handled in 1)
      - otherwise, this request will be dispatched after any in-flight IO is
        completed via blk_mq_sched_restart()
      
      3) if SCHED_RESTART is set concurently in context because of
      BLK_STS_RESOURCE, blk_mq_delay_run_hw_queue() will cover the above two
      cases and make sure IO hang can be avoided.
      
      One invariant is that queue will be rerun if SCHED_RESTART is set.
      Suggested-by: NJens Axboe <axboe@kernel.dk>
      Tested-by: NLaurence Oberman <loberman@redhat.com>
      Signed-off-by: NMing Lei <ming.lei@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      86ff7c2a