Re: [PATCH 03/11] sched_ext: Block proxy donors across scheduler transitions
John Stultz <[email protected]> Fri, 17 Jul 2026 20:16:46 -0700
| Newsgroups | dev.linux.lists.sched-ext,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CANDhNCr33ZFdWHcMNU3QS4DiV36Vo_Kq1tP3uZBJXXEJEb4rnA@mail.gmail.com> |
On Thu, Jul 16, 2026 at 6:23 AM Andrea Righi <[email protected]> wrote: > > Proxy execution retains mutex-blocked donors on the runqueue so their > scheduling context can execute a lock owner. sched_ext cannot safely > retain such donors unless the BPF scheduler explicitly participates in > their admission and ordering. > > Make sched_ext reject retained donors by default. Force blocked EXT > tasks through the regular block path in schedule(), and fully deactivate > a retained donor before sched_setscheduler(), PI de-boosting, or global > activation moves it into the EXT class. These hooks establish the safe > default that a later opt-in can relax. > > This is a preparatory change to support proxy execution with sched_ext. > > Signed-off-by: Andrea Righi <[email protected]> > --- > kernel/sched/core.c | 5 ++++- > kernel/sched/ext/ext.c | 44 +++++++++++++++++++++++++++++++++++++++++ > kernel/sched/ext/ext.h | 6 ++++++ > kernel/sched/syscalls.c | 3 +++ > 4 files changed, 57 insertions(+), 1 deletion(-) > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index e7827cffc2f0c..ddc832035854b 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -7173,7 +7173,8 @@ static void __sched notrace __schedule(int sched_mode) > * task_is_blocked() will always be false). > */ > try_to_block_task(rq, prev, &prev_state, > - !task_is_blocked(prev)); > + !task_is_blocked(prev) || > + !scx_allow_proxy_exec(prev)); > switch_count = &prev->nvcsw; > } This reminds me that since we no longer re-use try_to_block_task() elsewhere, we can probably push the checks down into the function and get rid of teh should_block argument. But this is a minor cleanup for later, not an issue with this patch. This looks good to me! Acked-by: John Stultz <[email protected]>