On 5/29/19 9:36 PM, Bart Van Assche wrote:
On 5/29/19 10:38 AM, Hannes Reinecke wrote:
On 5/29/19 5:19 PM, Bart Van Assche wrote:
On 5/29/19 6:28 AM, Hannes Reinecke wrote:
+ rq = blk_mq_alloc_request(shost->reserved_cmd_q,
+ REQ_OP_DRV_OUT | REQ_NOWAIT,
+ BLK_MQ_REQ_RESERVED);
Is your purpose to avoid that blk_mq_alloc_request() waits? If so,
why do you want to avoid that?
Typically these commands are intended for internal purposes, so there
should always be enough commands free to allow direct allocation.
If not we're in an error condition, and we need to return so as not to
lock up the driver (as it might rely on this command to make forward
progress).
That sounds like a risky strategy to me. blk_mq_alloc_request() can
block for a number of reasons, e.g. because a request queue due to e.g.
CPU hotplugging. I don't think that you want
scsi_host_get_reserved_cmd() or scsi_get_reserved_cmd() to fail if a
request queue is frozen.
Au contraire.
These commands are intended for driver internals (like sending TMFs
etc). Drivers can handle a failure here pretty well, as then the driver
will just escalate things internally. A stall, OTOH, would lock up the
entire driver.
Think of Task Abort TMF: it's okay (and actually expected) for the TMF
to fail; the driver will just escalate things internally.
It is, however, _not_ okay to stall for that command to become available
(eg if all tags are used up, and we now have to start aborting
commands), as this will stall or even live-lock the entire driver.
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
