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

From: Haris Iqbal

Date: Tue Aug 11 2026 - 18:40:19 EST


On Wed, Jul 22, 2026 at 3:46 PM Haris Iqbal <haris.iqbal@xxxxxxxxxxxxxxx> wrote:
>
> On Wed, Jul 15, 2026 at 3:56 PM Md Haris Iqbal <haris.iqbal@xxxxxxxxx> 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 <haris.iqbal@xxxxxxxxx>
> > ---
> > 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