Re: [PATCH] scsi: mpt3sas: don't post task management replies to io_uring poll queues

On Wed, Jul 22, 2026 at 3:46 PM Haris Iqbal <[email protected]> wrote:
>
> On Wed, Jul 15, 2026 at 3:56 PM Md Haris Iqbal <[email protected]> wrote:
> >
> > mpt3sas_scsih_issue_tm() posts a task management (TM) request to the
> > reply queue given by @msix_task. For ABORT_TASK and the broadcast
> > primitive QUERY_TASK/ABORT_TASK paths, @msix_task is the msix_io of the
> > command being managed; for an io_uring polled (RWF_HIPRI) command that is
> > an io_uring poll reply queue (index >= ioc->iopoll_q_start_index).
> >
> > io_uring poll queues have no MSI-X interrupt registered and are drained
> > only by mpt3sas_blk_mq_poll(), which the block layer calls to complete
> > polled block I/O. A task management request is not a block layer request,
> > so nothing polls on its behalf: the reply is posted to a queue that is
> > never serviced during the wait, tm_cmds.done is never completed, and the
> > TM times out even though the controller is healthy. The abort then
> > escalates to a controller reset that was not needed.
> >
> > Post TM replies to reply queue 0 whenever the selected reply queue is an
> > io_uring poll queue; reply queue 0 is always interrupt-serviced. When
> > poll queues are disabled, iopoll_q_start_index equals reply_queue_count,
> > so the check is a no-op and behaviour is unchanged.
> >
> > Reachable only when the driver is loaded with poll_queues > 0 and an
> > io_uring polled workload issues I/O that later times out and is aborted.
> >
> > Fixes: 432bc7caef4e ("scsi: mpt3sas: Add io_uring iopoll support")
> > Signed-off-by: Md Haris Iqbal <[email protected]>
> > ---
> > Found by code inspection while auditing the task-management reply path.
> > Posting for review of the analysis.
>
> Gentle ping.

Yet another ping!

>
> >
> >  drivers/scsi/mpt3sas/mpt3sas_scsih.c | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> > index 12caffeed3a0..572ec1787e10 100644
> > --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> > +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> > @@ -3186,6 +3186,16 @@ mpt3sas_scsih_issue_tm(struct MPT3SAS_ADAPTER *ioc, u16 handle, uint channel,
> >         int_to_scsilun(lun, (struct scsi_lun *)mpi_request->LUN);
> >         mpt3sas_scsih_set_tm_flag(ioc, handle);
> >         init_completion(&ioc->tm_cmds.done);
> > +       /*
> > +        * A task management reply must be posted to an interrupt-serviced
> > +        * reply queue. If the associated command was submitted on an io_uring
> > +        * poll queue, that queue has no MSI-X interrupt and is drained only by
> > +        * mpt3sas_blk_mq_poll(); a task management request is not a block layer
> > +        * request, so nothing would process its reply and the command would
> > +        * time out. Fall back to reply queue 0 in that case.
> > +        */
> > +       if (msix_task >= ioc->iopoll_q_start_index)
> > +               msix_task = 0;
> >         ioc->put_smid_hi_priority(ioc, smid, msix_task);
> >         wait_for_completion_timeout(&ioc->tm_cmds.done, timeout*HZ);
> >         if (!(ioc->tm_cmds.status & MPT3_CMD_COMPLETE)) {
> > --
> > 2.43.0
> >
>
>
> --
>
> Regards
> -Haris