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

From: Huacai Chen

Date: Fri Nov 13 2026 - 01:46:23 EST


On Thu, Nov 12, 2026 at 4:13 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> 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.
OK, now I know my skip condition bypasses too many cases, then is it
acceptable to use "if (!IS_ENABLED(CONFIG_SMP))"? In this way the SMP
behaviours are the same as before.

Huacai

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