From: sashiko-bot@kernel.org
To: "Ivy Lopez" <skunkolee@gmail.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH v2] scsi: mpt3sas: avoid out-of-bounds cpumask_of_node() call in _base_assign_reply_queues()
Date: Tue, 25 Aug 2026 19:17:29 +0000 [thread overview]
Message-ID: <20260825191729.ED3911F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260825190313.24013-1-skunkolee@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but incorrect subtraction in the fall_back path causes unassigned CPUs in the msix table and a potential divide by zero if nr_msix evaluates to zero.
--
commit 9e90c3b985462523aebc40d2af67de713d3be849
Author: Ivy Lopez <skunkolee@gmail.com>
scsi: mpt3sas: avoid out-of-bounds cpumask_of_node() call in _base_assign_reply_queues()
dev_to_node() can return NUMA_NO_NODE (-1) on systems without NUMA
topology information for the PCI device, such as single-socket
boards that don't expose device-to-node affinity. Fall back to
cpu_online_mask when no NUMA node is available, rather than assuming
dev_to_node() always returns a valid node index.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221294
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c b/drivers/scsi/mpt3sas/mpt3sas_base.c
> index fed7aeffec58d..1af25a22611a1 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
> @@ -3238,7 +3238,10 @@ _base_assign_reply_queues(struct MPT3SAS_ADAPTER *ioc)
> * corresponding to high iops queues.
> */
> if (ioc->high_iops_queues) {
> - mask = cpumask_of_node(dev_to_node(&ioc->pdev->dev));
> + int node = dev_to_node(&ioc->pdev->dev);
> +
> + mask = (node == NUMA_NO_NODE) ?
> + cpu_online_mask : cpumask_of_node(node);
> for (index = 0; index < ioc->high_iops_queues;
> index++) {
> irq = pci_irq_vector(ioc->pdev, index);
[Severity: High]
This isn't a bug introduced by this patch, but incorrect subtraction in the
fall_back path causes unassigned CPUs in the msix table and a potential
divide by zero.
In _base_assign_reply_queues(), the calculation evaluates incorrectly:
drivers/scsi/mpt3sas/mpt3sas_base.c:_base_assign_reply_queues() {
...
fall_back:
cpu = cpumask_first(cpu_online_mask);
nr_msix -= (ioc->high_iops_queues - iopoll_q_count);
index = 0;
list_for_each_entry(reply_q, &ioc->reply_queue_list, list) {
unsigned int i, group = nr_cpus / nr_msix;
...
}
If iopoll_q_count > 0, the calculation nr_msix -= (ioc->high_iops_queues -
iopoll_q_count) evaluates to nr_msix - high_iops_queues + iopoll_q_count.
This mathematically adds iopoll_q_count instead of subtracting it, inflating
nr_msix. This causes group = nr_cpus / nr_msix to calculate a smaller group
size, leaving trailing CPUs mapped to vector 0.
Furthermore, if PCI MSI-X allocation limits nr_msix to exactly
high_iops_queues (e.g. system interrupt limits), nr_msix evaluates to 0.
This would trigger a hardware divide-by-zero exception when evaluating
nr_cpus / nr_msix.
Is it possible to rewrite this subtraction to avoid inflating nr_msix and
prevent a potential divide-by-zero?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260825190313.24013-1-skunkolee@gmail.com?part=1
next prev parent reply other threads:[~2026-08-25 19:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 22:13 [PATCH] scsi: mpt3sas: avoid out-of-bounds cpumask_of_node() call in _base_assign_reply_queues() Ivy Lopez
2026-08-17 22:30 ` sashiko-bot
2026-08-18 12:46 ` Johannes Thumshirn
2026-08-18 15:09 ` John Garry
2026-08-25 19:03 ` [PATCH v2] " Ivy Lopez
2026-08-25 19:17 ` sashiko-bot [this message]
2026-09-01 10:21 ` John Garry
2026-09-03 3:10 ` Martin K. Petersen (Oracle)
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=20260825191729.ED3911F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=skunkolee@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.