Linux proxy execution gains optional sched_ext BPF support

Andrea Righi has posted a Linux kernel patch series that lets proxy execution and sched_ext coexist in the same build, ending a compile-time mutual exclusion that forced distributors to pick one feature or the other.

Proxy execution lets a task blocked on a mutex donate its scheduling context to the lock owner. The owner then runs with the waiter's priority and runtime budget while the donor stays eligible on the runqueue, which reduces priority inversion. sched_ext, the BPF extensible scheduling class, could not share a kernel with that path. A proxy handoff can put a task on the CPU that the BPF scheduler never dispatched, so helpers and Dispatch Queue bookkeeping can see a current task that does not match BPF state.

The series, building on early work by John Stultz, makes support optional per BPF scheduler. A new ops flag keeps mutex-blocked donors runnable and delivers them through the enqueue callback marked as blocked, so BPF controls whether, where, and in what order each donor is placed. Schedulers that omit the flag reject retained donors and block them on the ordinary path. Retained proxy sessions are dropped on scheduler ownership changes so an incoming BPF program always starts from clean task state.

Preparatory fixes close related gaps. Bandwidth accounting now consults the selected donor rather than only the physical current task when deciding whether the tick may stop, so a constrained fair donor is not ignored. Moving a blocked donor's scheduling context no longer trips migration-disabled warnings, because the execution context stays put until wakeup. A race under proxy execution that could migrate an active context and trigger sleeping-while-atomic warnings under load parks the task for reenqueue once resolution settles, following a suggestion from Tejun Heo.

Selftests cover priority inversion on same-CPU and cross-CPU donor and owner layouts with a weighted-vruntime BPF scheduler.