From: sashiko-bot@kernel.org
To: "Florian Bezdeka" <florian.bezdeka@siemens.com>
Cc: linux-rt-devel@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 1/3] cpumask: Honor irq_default_affinity in cpumask_local_spread()
Date: Thu, 20 Aug 2026 14:30:46 +0000 [thread overview]
Message-ID: <20260820143046.D2C641F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260819-flo-net-7-2-make-stmmac-default-affinity-aware-v1-1-3f79a99cadaf@siemens.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] cpumask_local_spread() can return an invalid CPU index (>= nr_cpu_ids) when offline CPUs are present in irq_default_affinity, leading to out-of-bounds memory accesses in callers.
- [High] Unprotected, non-atomic accesses to irq_default_affinity in cpumask_local_spread() can race with concurrent updates from procfs, causing a division by zero or an out-of-bounds index return.
--
--- Patch [1]: [PATCH RFC 1/3] cpumask: Honor irq_default_affinity in cpumask_local_spread() ---
commit 451b7ef83d22392d8351ba057c391bf3a21095c8
Author: Florian Bezdeka <florian.bezdeka@siemens.com>
cpumask: Honor irq_default_affinity in cpumask_local_spread()
This patch updates cpumask_local_spread() to honor irq_default_affinity
instead of cpu_online_mask. This aims to prevent IRQs from targeting
isolated CPUs for workloads like PREEMPT_RT.
> diff --git a/lib/cpumask.c b/lib/cpumask.c
> index 5adb9874fbd0f..73e7b60a92011 100644
> --- a/lib/cpumask.c
> +++ b/lib/cpumask.c
[ ... ]
> @@ -110,9 +112,9 @@ unsigned int cpumask_local_spread(unsigned int i, int node)
> unsigned int cpu;
>
> /* Wrap: we always want a cpu. */
> - i %= num_online_cpus();
> + i %= cpumask_weight(irq_default_affinity);
[Severity: High]
Is it possible for a concurrent write to irq_default_affinity to cause a
division by zero?
Userland can update the mask via /proc/irq/default_smp_affinity, which
uses a non-atomic cpumask_copy() in default_affinity_write().
If cpumask_local_spread() locklessly computes the weight while bits are
being copied, could it momentarily observe a weight of 0 and trigger a
division by zero panic here?
>
> - cpu = sched_numa_find_nth_cpu(cpu_online_mask, i, node);
> + cpu = sched_numa_find_nth_cpu(irq_default_affinity, i, node);
[Severity: Critical]
Does this code return an invalid CPU index if there are offline CPUs
present in irq_default_affinity?
The modulo above uses cpumask_weight(irq_default_affinity), which
counts all bits in the mask regardless of whether the CPUs are online.
However, sched_numa_find_nth_cpu() only searches within cpu_online_mask:
include/linux/topology.h:sched_numa_find_nth_cpu() {
return cpumask_nth_and(cpu, cpus, cpu_online_mask);
}
If irq_default_affinity contains offline CPUs, the weight can be larger than
the number of online CPUs.
If i ends up larger than or equal to the number of online CPUs in the mask,
won't sched_numa_find_nth_cpu() fail and return an index >= nr_cpu_ids,
causing out-of-bounds memory accesses in callers?
>
> WARN_ON(cpu >= nr_cpu_ids);
> return cpu;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260819-flo-net-7-2-make-stmmac-default-affinity-aware-v1-0-3f79a99cadaf@siemens.com?part=1
next prev parent reply other threads:[~2026-08-20 14:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-19 14:30 [PATCH RFC 0/3] genirq: Allow drivers to respect userspace IRQ affinities Florian Bezdeka
2026-08-19 14:30 ` [PATCH RFC 1/3] cpumask: Honor irq_default_affinity in cpumask_local_spread() Florian Bezdeka
2026-08-19 18:38 ` Yury Norov
2026-08-20 16:09 ` Sebastian Andrzej Siewior
2026-08-20 14:30 ` sashiko-bot [this message]
2026-08-19 14:30 ` [PATCH RFC 2/3] genirq: Honor existing IRQ affinities when setting affinity hints Florian Bezdeka
2026-08-20 14:30 ` sashiko-bot
2026-08-20 16:41 ` Jakub Kicinski
2026-08-19 14:30 ` [PATCH RFC 3/3] net: stmmac: Migrate IRQ balancing to cpumask_local_spread() Florian Bezdeka
2026-08-19 18:45 ` Yury Norov
2026-08-20 14:30 ` sashiko-bot
2026-08-19 18:28 ` [PATCH RFC 0/3] genirq: Allow drivers to respect userspace IRQ affinities Yury Norov
2026-08-19 23:54 ` Andrew Lunn
2026-08-20 0:10 ` Andrew Lunn
2026-08-20 15:12 ` Sebastian Andrzej Siewior
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=20260820143046.D2C641F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=florian.bezdeka@siemens.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=sashiko-reviews@lists.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 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.