On Tue, 15 Sep 2026 13:29:19 +0000, [email protected] wrote:
> > +   if (!(ct_rcu_watching_cpu(cpu) & CT_RCU_WATCHING))
> > +           return true;
> > +   return idle_cpu(cpu);
> > +}
>
> [Severity: High]
> Could the unconditional return of idle_cpu() lead to a use-after-free crash
> if the idle task was interrupted in trampoline code?

Yes, this one is right. The classic flavor ignores idle tasks too and
leans on Tasks Rude for that, but the idle_cpu() shortcut here made it
worse than it needs to be: an idle CPU with an interrupt sitting on top
of a trampoline the idle loop had called into would be passed
immediately, and since idle is never preempted from irq exit nothing
else catches it.

For v4 that line is gone and an idle CPU only counts while RCU is not
watching it. If it is watching (the interrupt, or the traceable part of
the idle loop) it gets the resched_cpu() like any other straggler and
counts once the idle loop itself schedules, which it cannot do from
inside a trampoline. So idle ends up covered rather than ignored.

Thanks,

Josef

Reply via email to