On Thu, Dec 16, 2021 at 05:25:41PM +0530, Kashyap Desai wrote: > > > > > > I mean, shared bitmap in my whole discussion. Megaraid_sas driver use > > > shared bitmap, so it is exposed and It is confirmed from this > discussion. > > > Do we still have exposure (if "blk-mq: avoid to iterate over stale > > > request" is not part of kernel) to mpi3mr type driver which does not > > > use shared bitmap but has nr_hw_queues > 1. ? > > > > Not sure I understand your poing, but patch "blk-mq: avoid to iterate > over > > stale request" can cover both shared tags or not. > > I agree with all above reply. > > My query is for mpi3mr driver which is not calling "host->host_tagset = > 1;", but nr_hw_queues are more than 1. > Current <mpi3mr> driver is nvme style interface. nr_hw_queues > 1 and > host->host_tagset = 0. > > Is this patch "blk-mq: avoid to iterate over stale request" is applicable > for <mpi3mr> driver ? Yeah, this change covers both ->host_tagset and !->host_tagset, same with the following words: scsi_host_check_in_flight() is used to counting scsi in-flight requests after scsi host is blocked, so no new scsi command can be marked as SCMD_STATE_INFLIGHT. However, driver tag allocation still can be run at that time by blk-mq core. The issue is in blk_mq_tagset_busy_iter(). One request is in-flight, but this request may be kept in another slot of ->rqs[], meantime the slot can be allocated out but ->rqs[] isn't updated yet. Then the in-flight request is counted twice as SCMD_STATE_INFLIGHT. Thanks, Ming
