[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

[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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] lib/smp_processor_id: check_preemption_disabled() disables
  checks when 1 CPU
- [Low] lib/smp_processor_id: missing Fixes trailer on stable bug-fix
  commit
--

commit 0181ac5af2fbbf50ee4ee229425b805d588cbf1c
Author: Huacai Chen <chenhuacai@kernel.org>

> lib/smp_processor_id: Don't warn if there is only one CPU
>
> 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>

[Severity: Low]
This commit is tagged for stable backporting to fix the !CONFIG_SMP warning
exposed when is_percpu_thread() was made unconditional of CONFIG_SMP.
Should it include a Fixes: tag such as:

  Fixes: 06ddd17521bf ("sched/smp: Always define is_percpu_thread() and scheduler_ipi()")

> diff --git a/lib/smp_processor_id.c b/lib/smp_processor_id.c
> index 94b3f6b195388..64901d33c0eee 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;

[Severity: Medium]
Does returning early when nr_cpu_ids == 1 disable CONFIG_DEBUG_PREEMPT
checks across the entire kernel on single-CPU systems?

check_preemption_disabled() also backs __this_cpu_preempt_check().  Even
with a single CPU, preemptible code using __this_cpu_*() or per-CPU state
via smp_processor_id() can be preempted on CPU 0 by another task that
modifies the same per-CPU variable.

In addition, nr_cpu_ids == 1 is true at runtime on CONFIG_SMP=y kernels
booted on a 1-vCPU VM or with nr_cpus=1, and on !CONFIG_SMP builds
nr_cpu_ids is a compile-time constant 1, making the rest of
check_preemption_disabled() dead code and undoing 2885daf47081
("lib/smp_processor_id: Make migration check unconditional of SMP").

The reported warning happens because cpuhp_issue_call() on !CONFIG_SMP
invokes non-atomic hotplug callbacks directly in the calling task without
migrate_disable(), and init_cache_level() in
arch/loongarch/kernel/cacheinfo.c reads current_cpu_data instead of
cpu_data[cpu].  Could this be fixed in cpuhp_issue_call() or
arch/loongarch/kernel/cacheinfo.c instead of disabling
check_preemption_disabled()?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261111092421.3771992-1-chenhuacai@loongson.cn?part=1

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

[Steven Rostedt]

On Thu, 12 Nov 2026 09:13:48 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> 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.

Hmm, I was under the impression that there would always be a CPU 0.

Is it possible to boot with a non zero CPU setup?

-- Steve

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

[Peter Zijlstra]

On Thu, Nov 12, 2026 at 09:40:59AM -0500, Steven Rostedt wrote:
> On Thu, 12 Nov 2026 09:13:48 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > 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.
> 
> Hmm, I was under the impression that there would always be a CPU 0.
> 
> Is it possible to boot with a non zero CPU setup?

Yes. Voyager did that -- although that code is now long gone.

In general we must not assume boot cpu is 0 -- although I don't know of
any architecture that currently doesn't have that. Might be fun to have
it as a debug option to catch out assumptions.