scsi: mpt3sas: don't post task management replies to io_uring poll queues

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

Posted by Md Haris Iqbal 1 week, 3 days ago

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@ionos.com>
---
Found by code inspection while auditing the task-management reply path.
Posting for review of the analysis.

 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

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

Posted by Haris Iqbal 3 days, 3 hours ago

On Wed, Jul 15, 2026 at 3:56 PM Md Haris Iqbal <haris.iqbal@ionos.com> 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@ionos.com>
> ---
> Found by code inspection while auditing the task-management reply path.
> Posting for review of the analysis.

Gentle 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