[PATCH] lib/smp_processor_id: Don't warn if there is only one CPU

[PATCH] lib/smp_processor_id: Don't warn if there is only one CPU

[Huacai Chen]

When CONFIG_DEBUG_PREEMPT is enabled on a Non-SMP (single-core) kernel,
calls to smp_processor_id() in preemptible contexts trigger some false
positive "BUG: using smp_processor_id() in preemptible" warnings, which
are harmless noise because the process always executes on CPU 0 and CPU
migration is impossible.

Here are some of the trimmed log messages:

  Call Trace:
  [<9000000000d33e28>] show_stack+0xf8/0x1c0
  [<9000000000d2fdac>] dump_stack_lvl+0x4c/0x78
  [<9000000002456fc0>] check_preemption_disabled.isra.0+0x100/0x110
  [<9000000002456ff8>] debug_smp_processor_id+0x18/0x40
  [<9000000000d31118>] init_cache_level+0x18/0x90
  [<9000000001adbe2c>] detect_cache_attributes+0x4c/0x640
  [<9000000001adc44c>] cacheinfo_cpu_online+0x1c/0x310
  [<9000000000d5ae04>] cpuhp_issue_call.constprop.0+0x94/0xd0
  [<9000000000d5b278>] __cpuhp_setup_state_cpuslocked+0x208/0x320
  [<9000000000d30148>] do_one_initcall+0x68/0x200
  [<90000000024711b8>] kernel_init_freeable+0x1fc/0x294
  [<900000000245824c>] kernel_init+0x20/0x134
  [<9000000002455b54>] ret_from_kernel_thread+0x24/0x1d0
  [<9000000000d31650>] ret_from_kernel_thread_asm+0xc/0x9c

This warning only exists for the !CONFIG_SMP build. This is because for
CONFIG_SMP cpuhp_issue_call() invokes callbacks in cpuhp_thread_fun()
which is a percpu thread, but for !CONFIG_SMP build it invoke callbacks
in the init process which is not a percpu thread. And there is such a
skip condition in check_preemption_disabled():

    if (is_percpu_thread())
            goto out;

Since there is only one CPU for the !CONFIG_SMP, we can simply skip the
warning if (nr_cpu_ids == 1) in check_preemption_disabled().

Cc: stable@vger.kernel.org
Reported-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
---
 lib/smp_processor_id.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/smp_processor_id.c b/lib/smp_processor_id.c
index 94b3f6b19538..64901d33c0ee 100644
--- a/lib/smp_processor_id.c
+++ b/lib/smp_processor_id.c
@@ -19,6 +19,9 @@ unsigned int check_preemption_disabled(const char *what1, const char *what2)
 	if (irqs_disabled())
 		goto out;
 
+	if (nr_cpu_ids == 1)
+		goto out;
+
 	if (is_percpu_thread())
 		goto out;
 
-- 
2.52.0

Re: [PATCH] lib/smp_processor_id: Don't warn if there is only one CPU

[Peter Zijlstra]

On Wed, Nov 11, 2026 at 05:24:21PM +0800, Huacai Chen wrote:
> When CONFIG_DEBUG_PREEMPT is enabled on a Non-SMP (single-core) kernel,
> calls to smp_processor_id() in preemptible contexts trigger some false
> positive "BUG: using smp_processor_id() in preemptible" warnings, which
> are harmless noise because the process always executes on CPU 0 and CPU
> migration is impossible.

The check is still valid, you don't want to have any code that uses
smp_processor_id() outside of preempt_disable(). Such code would be
invalid on SMP, even when ran on UP.

All code must be SMP ready.

Aside from that, nr_cpu_ids is the wrong number to check.

Re: [PATCH] lib/smp_processor_id: Don't warn if there is only one CPU

[Huacai Chen]

Hi, Peter,

On Thu, Nov 12, 2026 at 1:06 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Wed, Nov 11, 2026 at 05:24:21PM +0800, Huacai Chen wrote:
> > When CONFIG_DEBUG_PREEMPT is enabled on a Non-SMP (single-core) kernel,
> > calls to smp_processor_id() in preemptible contexts trigger some false
> > positive "BUG: using smp_processor_id() in preemptible" warnings, which
> > are harmless noise because the process always executes on CPU 0 and CPU
> > migration is impossible.
>
> The check is still valid, you don't want to have any code that uses
> smp_processor_id() outside of preempt_disable(). Such code would be
> invalid on SMP, even when ran on UP.
Thank you for your reply.

At first I also think that smp_processor_id() should always be called
in preempt disabled context, but after investigation, I found:

There are 5 existing skip conditions.

1. if (likely(preempt_count()))
2. if (irqs_disabled())
3. if (is_percpu_thread())
4. if (current->migration_disabled)
5. if (system_state < SYSTEM_SCHEDULING)

Condition 1 and 2 is to make sure smp_processor_id() is called in
preempt disabled context, but Condition 3, 4 and 5 is not.

Condition 5 can make sure no context switching since the scheduler
hasn't begun to work, but Condition 3 and 4 can not.

In other words, Condition 3 and 4 can only make sure the current
execution will not be migrated to another CPU, and I think my new
condition is exactly the same.

>
> All code must be SMP ready.
This is why I use "if (nr_cpu_ids == 1)" rather than "if
(!IS_ENABLED(CONFIG_SMP))".

>
> Aside from that, nr_cpu_ids is the wrong number to check.
Correct me if I'm wrong, do you mean checking num_online_cpus()?


Huacai

Re: [PATCH] lib/smp_processor_id: Don't warn if there is only one CPU

[Peter Zijlstra]

On Thu, Nov 12, 2026 at 11:14:57AM +0800, Huacai Chen wrote:
> Hi, Peter,
> 
> On Thu, Nov 12, 2026 at 1:06 AM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Wed, Nov 11, 2026 at 05:24:21PM +0800, Huacai Chen wrote:
> > > When CONFIG_DEBUG_PREEMPT is enabled on a Non-SMP (single-core) kernel,
> > > calls to smp_processor_id() in preemptible contexts trigger some false
> > > positive "BUG: using smp_processor_id() in preemptible" warnings, which
> > > are harmless noise because the process always executes on CPU 0 and CPU
> > > migration is impossible.
> >
> > The check is still valid, you don't want to have any code that uses
> > smp_processor_id() outside of preempt_disable(). Such code would be
> > invalid on SMP, even when ran on UP.
> Thank you for your reply.
> 
> At first I also think that smp_processor_id() should always be called
> in preempt disabled context, but after investigation, I found:
> 
> There are 5 existing skip conditions.
> 
> 1. if (likely(preempt_count()))
> 2. if (irqs_disabled())
> 3. if (is_percpu_thread())
> 4. if (current->migration_disabled)
> 5. if (system_state < SYSTEM_SCHEDULING)
> 
> Condition 1 and 2 is to make sure smp_processor_id() is called in
> preempt disabled context, but Condition 3, 4 and 5 is not.
> 
> Condition 5 can make sure no context switching since the scheduler
> hasn't begun to work, but Condition 3 and 4 can not.
> 
> In other words, Condition 3 and 4 can only make sure the current
> execution will not be migrated to another CPU, and I think my new
> condition is exactly the same.

It is not; your patch would suppress any and all checks when ran with
just a single CPU. Even when the code is clearly buggered.

> > All code must be SMP ready.
> This is why I use "if (nr_cpu_ids == 1)" rather than "if
> (!IS_ENABLED(CONFIG_SMP))".
> 
> >
> > Aside from that, nr_cpu_ids is the wrong number to check.
> Correct me if I'm wrong, do you mean checking num_online_cpus()?

num_possible_cpus() is what I was thinking of. Notably, there is no
requirement that the CPU bitmap is dense. You can have nr_cpu_ids at 256
and use 255 for your boot CPU. It would be completely daft to do so, but
it is still valid.

Re: [PATCH] lib/smp_processor_id: Don't warn if there is only one CPU

[Tiezhu Yang]

On 11/11/26 5:24 PM, Huacai Chen wrote:
> When CONFIG_DEBUG_PREEMPT is enabled on a Non-SMP (single-core) kernel,
> calls to smp_processor_id() in preemptible contexts trigger some false
> positive "BUG: using smp_processor_id() in preemptible" warnings, which
> are harmless noise because the process always executes on CPU 0 and CPU
> migration is impossible.

...

> Reported-by: Tiezhu Yang <yangtiezhu@loongson.cn>

Hi all,

Just for reference, here is the related LoongArch patch that
fixes the specific callers in cacheinfo and local TLB flush:

LoongArch: Fix preemptible warnings in cacheinfo and local TLB flush
https://lore.kernel.org/loongarch/20261111113738.862-1-yangtiezhu@loongson.cn/T/#u

Thanks,
Tiezhu