public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Breno Leitao <leitao@debian.org>
To: Tejun Heo <tj@kernel.org>, Lai Jiangshan <jiangshanlai@gmail.com>
Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com,
	 kernel test robot <lkp@intel.com>,
	Breno Leitao <leitao@debian.org>
Subject: [PATCH v2] workqueue: validate cpumask_first() result in llc_populate_cpu_shard_id()
Date: Mon, 13 Apr 2026 07:26:47 -0700	[thread overview]
Message-ID: <20260413-workqueue_fix_nios-v2-1-2cf6a61b6bb3@debian.org> (raw)

On uniprocessor (UP) configs such as nios2, NR_CPUS is 1, so
cpu_shard_id[] is a single-element array (int[1]). In
llc_populate_cpu_shard_id(), cpumask_first(sibling_cpus) returns an
unsigned int that the compiler cannot prove is always 0, triggering
a -Warray-bounds warning when the result is used to index
cpu_shard_id[]:

  kernel/workqueue.c:8321:55: warning: array subscript 1 is above
  array bounds of 'int[1]' [-Warray-bounds]
   8321 |  cpu_shard_id[c] = cpu_shard_id[cpumask_first(sibling_cpus)];
        |                    ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is a false positive: sibling_cpus can never be empty here because
'c' itself is always set in it, so cpumask_first() will always return a
valid CPU. However, the compiler cannot prove this statically, and the
warning only manifests on UP configs where the array size is 1.

Add a bounds check with WARN_ON_ONCE to silence the warning, and store
the result in a local variable to make the code clearer and avoid calling
cpumask_first() twice.

Fixes: 5920d046f7ae3 ("workqueue: add WQ_AFFN_CACHE_SHARD affinity scope")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202604022343.GQtkF2vO-lkp@intel.com/
Signed-off-by: Breno Leitao <leitao@debian.org>
---
Changes in v2:
- Better describe the fix and that it only happens on UP configurations
  (tejun)
- Declare leader as unsigned.
- Link to v1: https://patch.msgid.link/20260410-workqueue_fix_nios-v1-1-abbb26575b1b@debian.org
---
 kernel/workqueue.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 083d8fe301f46..5f747f241a5f1 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -8298,6 +8298,7 @@ static void __init llc_populate_cpu_shard_id(const struct cpumask *pod_cpus,
 	const struct cpumask *sibling_cpus;
 	/* Count the number of cores in the current shard_id */
 	int cores_in_shard = 0;
+	unsigned int leader;
 	/* This is a cursor for the shards. Go from zero to nr_shards - 1*/
 	int shard_id = 0;
 	int c;
@@ -8318,7 +8319,17 @@ static void __init llc_populate_cpu_shard_id(const struct cpumask *pod_cpus,
 			 * The siblings' shard MUST be the same as the leader.
 			 * never split threads in the same core.
 			 */
-			cpu_shard_id[c] = cpu_shard_id[cpumask_first(sibling_cpus)];
+			leader = cpumask_first(sibling_cpus);
+
+			/*
+			 * This check silences a Warray-bounds warning on UP
+			 * configs where NR_CPUS=1 makes cpu_shard_id[]
+			 * a single-element array, and the compiler can't
+			 * prove the index is always 0.
+			 */
+			if (WARN_ON_ONCE(leader >= nr_cpu_ids))
+				continue;
+			cpu_shard_id[c] = cpu_shard_id[leader];
 		}
 	}
 

---
base-commit: 3fa7d958829eb9bc3b469ed07f11de3d2804ef71
change-id: 20260410-workqueue_fix_nios-e6763904aee9

Best regards,
--  
Breno Leitao <leitao@debian.org>


             reply	other threads:[~2026-04-13 14:28 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-13 14:26 Breno Leitao [this message]
2026-04-13 16:21 ` [PATCH v2] workqueue: validate cpumask_first() result in llc_populate_cpu_shard_id() Tejun Heo

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=20260413-workqueue_fix_nios-v2-1-2cf6a61b6bb3@debian.org \
    --to=leitao@debian.org \
    --cc=jiangshanlai@gmail.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=tj@kernel.org \
    /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