Re: [RFC PATCH v2] sched: irq: cpu-hotplug race vs set_cpus_allowed_ptr()

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-10-12 16:30:47 [+0200], Peter Zijlstra wrote:
> >   There is nothing that waits for the interrupt thread to complete,
> >   there is no synchronize_irq() invocation which would be required for
> >   the deadlock to happen.
> 
> But any other set_cpus_allowed_ptr() call in the kernel can suffer the
> same problem, no? Why is the irq thing 'special'?

Not saying this is special.

> I am struggling to follow along. The actual fail scenario is a
> combination of hotplug *and* migrate_disable()? Can we get a picture?

let me grab the reproducer and a few tracepoints to make an accurate
drawing.

> A CPU must not be able to go offline while there are migrate_disable()
> tasks on it. Are you saying the migrate_disable() happens after hotplug
> already marks the CPU offline?

I *think* there were no tasks on it. So based on fading out memory:
T on CPU0 in migrate_disable(), assigned to CPU1, schedule().
CPU1 about to go down while the T on CPU0 returns does
migrate_enable() and should migrate to CPU1.
But this old memory. Let me get the reproducer and get back to you.

Sebastian