From: Alan Stern <stern@rowland.harvard.edu>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Jens Axboe <axboe@kernel.dk>,
"Martin K . Petersen" <martin.petersen@oracle.com>,
"James E . J . Bottomley" <jejb@linux.vnet.ibm.com>,
linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
linux-scsi@vger.kernel.org, Can Guo <cang@codeaurora.org>,
Stanley Chu <stanley.chu@mediatek.com>,
Ming Lei <ming.lei@redhat.com>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>
Subject: Re: [PATCH 5/9] scsi: Do not wait for a request in scsi_eh_lock_door()
Date: Sun, 6 Sep 2020 12:03:57 -0400 [thread overview]
Message-ID: <20200906160357.GA741441@rowland.harvard.edu> (raw)
In-Reply-To: <20200906012219.17893-6-bvanassche@acm.org>
On Sat, Sep 05, 2020 at 06:22:15PM -0700, Bart Van Assche wrote:
> It is not guaranteed that a request is available when scsi_eh_lock_door()
> is called. Hence pass the BLK_MQ_REQ_NOWAIT flag to blk_get_request().
> This patch has a second purpose, namely preventing that
> scsi_eh_lock_door() deadlocks if sdev->request_queue is frozen and if a
> SCSI command is submitted to a SCSI device through a second request queue
> that has not been frozen.
I think it would help readers understand the reason for doing this if
you mentioned that scsi_eh_lock_door() is the only place in the SCSI
error handler that calls blk_get_request().
Also mention that an upcoming patch in this series requires the error
handler to work okay even when the device's request queue is frozen.
(That's what the second sentence of your description is getting at, but
the connection is not clear.)
Alan Stern
next prev parent reply other threads:[~2020-09-06 16:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-06 1:22 [PATCH 0/9] Rework runtime suspend and SCSI domain validation Bart Van Assche
2020-09-06 1:22 ` [PATCH 1/9] block: Fix a race in the runtime power management code Bart Van Assche
2020-09-06 1:22 ` [PATCH 2/9] ide: Do not set the RQF_PREEMPT flag for sense requests Bart Van Assche
2020-09-06 1:22 ` [PATCH 3/9] scsi: Pass a request queue pointer to __scsi_execute() Bart Van Assche
2020-09-06 1:22 ` [PATCH 4/9] scsi: Rework scsi_mq_alloc_queue() Bart Van Assche
2020-09-06 1:22 ` [PATCH 5/9] scsi: Do not wait for a request in scsi_eh_lock_door() Bart Van Assche
2020-09-06 16:03 ` Alan Stern [this message]
2020-09-06 1:22 ` [PATCH 6/9] scsi_transport_spi: Make spi_execute() accept a request queue pointer Bart Van Assche
2020-09-06 1:22 ` [PATCH 7/9] scsi_transport_spi: Freeze request queues instead of quiescing Bart Van Assche
2020-09-09 3:51 ` Bart Van Assche
2020-09-06 1:22 ` [PATCH 8/9] block, scsi, ide: Only process PM requests if rpm_status != RPM_ACTIVE Bart Van Assche
2020-09-06 1:22 ` [PATCH 9/9] block: Do not accept any requests while suspended Bart Van Assche
2020-09-06 16:06 ` [PATCH 0/9] Rework runtime suspend and SCSI domain validation Alan Stern
2020-09-19 3:45 ` Bart Van Assche
2020-09-21 6:00 ` Hannes Reinecke
2020-09-30 2:47 ` Martin K. Petersen
2020-09-29 12:33 ` Martin Kepplinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200906160357.GA741441@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=cang@codeaurora.org \
--cc=hch@lst.de \
--cc=jejb@linux.vnet.ibm.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=ming.lei@redhat.com \
--cc=rafael.j.wysocki@intel.com \
--cc=stanley.chu@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox