Hi James, > On Thu, 2021-10-28 at 08:59 -0700, Bart Van Assche wrote: > > On 10/28/21 7:28 AM, James Bottomley wrote: > > > If the block people are happy with this, then I'm OK with it, but > > > it > > > doesn't look like you've solved the fanout deadlock problem because > > > this new mechanism is still going to allocate a new tag. > > > > (+Jens, Christoph and linux-block) > > > > Hi James, > > > > My understanding is that the UFS HPB code makes ufshcd_queuecommand() > > return SCSI_MLQUEUE_HOST_BUSY if the pool with pre-allocated requests > > is exhausted. This will make the SCSI core reissue a SCSI command > > until completion of another command has freed up one of the pre- > > allocated requests. This is not the most efficient approach but > > should not trigger a deadlock. > > I think the deadlock is triggered if the system is down to its last > reserved request on the memory clearing device and the next entry in > the queue for this device is one which does a fanout so we can't > service it with the single reserved request we have left for the > purposes of making forward progress. Sending it back doesn't help, > assuming this is the only memory clearing path, because retrying it > won't help ... we have to succeed with a request on this path to move > forward with clearing memory. The above approach can retry several times (before the HPB timeout) but, it gives up to allocate pre-request and it sends as just READ. So deadlock can be avoided. Thanks, Daejun
