From: sashiko-bot@kernel.org
To: "Usama Arif" <usama.arif@linux.dev>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH 1/2] scsi: mpi3mr: Poll a reply queue that an interrupt found busy
Date: Wed, 30 Sep 2026 15:10:39 +0000 [thread overview]
Message-ID: <20260930151039.F23801F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260930145606.2632749-2-usama.arif@linux.dev>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] scsi: mpi3mr: unhandled missed reply race under PREEMPT_RT
--
commit c0b0a317901b4ce93a734871bf41b604287947d5
Author: Usama Arif <usama.arif@linux.dev>
scsi: mpi3mr: Poll a reply queue that an interrupt found busy
This patch sets a flag to trigger a thread wakeup when an interrupt finds a
reply queue busy. It aims to prevent missed replies when another context
owns the queue.
> diff --git a/drivers/scsi/mpi3mr/mpi3mr_fw.c b/drivers/scsi/mpi3mr/mpi3mr_fw.c
> index f0d3cd398dd00..102f84667a5cf 100644
> --- a/drivers/scsi/mpi3mr/mpi3mr_fw.c
> +++ b/drivers/scsi/mpi3mr/mpi3mr_fw.c
[ ... ]
> @@ -588,8 +588,11 @@ int mpi3mr_process_op_reply_q(struct mpi3mr_ioc *mrioc,
>
> reply_qidx = op_reply_q->qid - 1;
>
> - if (!atomic_add_unless(&op_reply_q->in_use, 1, 1))
> + if (!atomic_add_unless(&op_reply_q->in_use, 1, 1)) {
> + /* The owner may have missed a reply, let the thread poll */
> + WRITE_ONCE(op_reply_q->enable_irq_poll, true);
[Severity: High]
When this code executes in mpi3mr_process_op_reply_q() under PREEMPT_RT,
does it leave missed IO replies stranded?
Under CONFIG_PREEMPT_RT, the interrupt handler is mpi3mr_isr_primary(),
which exits without checking the enable_irq_poll flag or returning
IRQ_WAKE_THREAD.
Additionally, looking at how the interrupt is requested:
drivers/scsi/mpi3mr/mpi3mr_fw.c:mpi3mr_request_irq() {
...
#else
retval = request_threaded_irq(pci_irq_vector(pdev, index), mpi3mr_isr_primary,
NULL, IRQF_SHARED, intr_info->name, intr_info);
#endif
...
}
Because the polling thread handler is explicitly NULL under PREEMPT_RT,
there is no polling thread to wake up to process the missed replies.
Could this cause SCSI command timeouts and host resets during concurrent
IO under PREEMPT_RT?
> return 0;
> + }
>
> exp_phase = op_reply_q->ephase;
> reply_ci = op_reply_q->ci;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260930145606.2632749-1-usama.arif@linux.dev?part=1
next prev parent reply other threads:[~2026-09-30 15:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 14:55 [PATCH 0/2] scsi: mpi3mr: Stop IRQ polling when no reply is ready Usama Arif
2026-09-30 14:55 ` [PATCH 1/2] scsi: mpi3mr: Poll a reply queue that an interrupt found busy Usama Arif
2026-09-30 15:10 ` sashiko-bot [this message]
2026-10-01 10:49 ` Usama Arif
2026-09-30 14:55 ` [PATCH 2/2] scsi: mpi3mr: Stop IRQ polling when no reply is ready Usama Arif
2026-09-30 15:20 ` sashiko-bot
2026-10-01 10:50 ` Usama Arif
2026-10-01 10:51 ` [PATCH 0/2] " Usama Arif
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260930151039.F23801F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=usama.arif@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox