[PATCH] nvme-fabrics -in case of REQ_NVME_MPATH we should return BLK_STS_RESOURCE

[hch@lst.de (hch@lst.de)]

On Thu, Sep 20, 2018@04:39:24PM -0700, James Smart wrote:
>> The multipath code handles failures from nvme_complete_rq just fine,
>> in fact even with this patch we still don't accept the command into
>> queue_rq.  It is just that BLK_STS_RESOURCE is a magic indicator
>> for the blk-mq core to retry internally and not hand it back to the
>> next higher level (which would be the multipath code, either nvme
>> or dm for that matter).
>
> your response is a bit cryptic

Or confused.  I meant handles failures from nvme_*queue_rq just fine
above.

> I agree with you - that nvme_complete_rq() handles it fine. But in the path 
> where the transport->queue_rq() is called, and the io is bounced due to 
> controller state checks, nvme_complete_rq() isn't being called.? If 
> queue_rq() return BLK_STS_RESOURCE, its ok as the io gets requeued in 
> blk-mq, but it could sit there for 60s or so. But if queue_rq() see the io 
> marked NVME_MPATH, it returns BLK_STS_IOERR? (blk_mq_complete_request() 
> isn't called), and the blk-mq layer ends up calling blk_mq_end_request().

Yes.  And that is probably why the current code is doing the right(-ish)
thing.