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