Re: [PATCHSET sched_ext/for-7.3] sched_ext: NMI-safe exit handling

On Fri, Jul 24, 2026 at 02:50:14PM -1000, Tejun Heo wrote:
> Hello,
> 
> The exit paths weren't NMI-safe: exit claiming walked the sub-scheduler
> hierarchy under scx_sched_lock and the bstr exit kfuncs formatted their
> messages into a shared buffer under a raw spinlock. Kfuncs in the "any"
> category are callable from tracing progs that can attach to functions
> running in NMI, and many of them raise scx_error() on invalid inputs, so
> an unlucky bad argument from such a prog could deadlock the machine. The
> hardlockup handler had the same problem and deferred its abort to an
> irq_work, which can't even run on the CPU that detected the lockup.
> 
> This series makes exit handling NMI-safe end to end:
> 
>  0001 makes exit claiming lock-free: ->aborting is asserted with a
>       synchronous lockless sweep and the locked SCX_EXIT_PARENT
>       propagation is deferred to an irq_work.
> 
>  0002 reverses the bstr exit sequence to claim-first so the message is
>       formatted directly into the winner-owned exit_info buffer. With
>       these two, scx_bpf_error() and scx_bpf_exit() are safe from any
>       context including NMI.
> 
>  0003-0005 apply the newly-possible direct error reporting: NMI kicks
>       abort the scheduler instead of being silently dropped, the
>       hardlockup handler aborts directly from NMI making self-detected
>       lockups recoverable, and scx_link_sched() reports failures inline.
> 
>  0001-sched_ext-Make-exit-claiming-lock-free.patch
>  0002-sched_ext-Format-bstr-exit-messages-after-claiming-t.patch
>  0003-sched_ext-Report-NMI-kicks-with-scx_error.patch
>  0004-sched_ext-Abort-directly-from-the-hardlockup-handler.patch
>  0005-sched_ext-Report-scx_link_sched-failures-inline.patch

With the new patch 1/5:

Reviewed-by: Andrea Righi <[email protected]>

Thanks,
-Andrea