On Mon, Aug 30, 2021 at 8:10 AM Bart Van Assche <bvanassche@xxxxxxx> wrote:
>
> On 7/27/21 01:12, Sreekanth Reddy wrote:
> > + /*
> > + * wait for current poll to complete.
> > + */
> > + for (qid = 0; qid < iopoll_q_count; qid++) {
> > + while (atomic_read(&ioc->io_uring_poll_queues[qid].busy))
> > + udelay(500);
> > + }
>
> So this loop busy-waits without calling cpu_relax()? That's not OK ...
I will post a new patch for calling this cpu_relax() API.
>
> An additional question: is mpt3sas_base_hard_reset_handler() the only
> function that calls mpt3sas_base_pause_mq_polling() and
> mpt3sas_base_resume_mq_polling()? If so, why have these functions been
> introduced since the SCSI core guarantees that all pending requests
> either have failed or have timed out before the SCSI error handler is
> invoked?
Hard reset is even called from IOCTL path while performing the IOC
firmware update operation, it is also called to recover the IOC from
fault state. During hard reset operation the driver returns all the
outstanding SCSI IO commands with DID_RESET host byte asking the SCSI
core to retry these IOs. So, before flushing out the outstanding IO
commands driver has to pause the mq polling to avoid the race
condition of completing the same SCSI IO command from two paths.
>
> Thanks,
>
> Bart.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
