On 10/27/21 9:03 AM, Ming Lei wrote: > On Wed, Oct 27, 2021 at 07:12:31AM -0700, Keith Busch wrote: >> On Wed, Oct 27, 2021 at 06:16:19AM -0700, Bart Van Assche wrote: >>> On 10/26/21 10:27 PM, Christoph Hellwig wrote: >>>> On Tue, Oct 26, 2021 at 01:10:47PM -0700, Bart Van Assche wrote: >>>>> If blk_insert_cloned_request() is moved into the device mapper then I >>>>> think that blk_mq_request_issue_directly() will need to be exported. >>>> >>>> Which is even worse. >>>> >>>>> How >>>>> about the (totally untested) patch below for removing the >>>>> blk_insert_cloned_request() call from the UFS-HPB code? >>>> >>>> Which again doesn't fix anything. The problem is that it fans out one >>>> request into two on the same queue, not the specific interface used. >>> >>> That patch fixes the reported issue, namely removing the additional accounting >>> caused by calling blk_insert_cloned_request(). Please explain why it is >>> considered wrong to fan out one request into two. That code could be reworked >>> such that the block layer is not involved as Adrian Hunter explained. However, >>> before someone spends time on making these changes I think that someone should >>> provide more information about why it is considered wrong to fan out one request >>> into two. >> >> The original request consumes a tag from that queue's tagset. If the >> lifetime of that tag depends on that same queue having another free tag, >> you can deadlock. > > Just take a quick look at the code, if the spawned request can't be allocated, > scsi will return BLK_STS_RESOURCE for the original scsi request which will be > retried later by blk-mq. > > So if tag depth is > 1 and max allowed inflight write buffer command is limited > as 1, there shouldn't be the deadlock. > > Or is it possible to reuse the original scsi request's tag for the > spawned request? Like the trick used in inserting flush request. The flush approach did come to mind here as well, but honestly that one is very ugly and would never have been permitted if it wasn't excluded to be in the very core code already. But yes, reuse of the existing request is probably another potentially viable approach. My worry there is that inevitably you end up needing to stash a lot of data to restore the original, and we're certainly not adding anything to struct request for that. Hence I think being able to find a new request reliably would be better. -- Jens Axboe
