Re: [PATCH 06/10] sched_ext: Delegate proxy donor admission to BPF schedulers

[Andrea Righi]

Hi John,

On Fri, Jul 10, 2026 at 06:43:44PM -0700, John Stultz wrote:
> On Fri, Jul 10, 2026 at 1:40 AM Andrea Righi <arighi@xxxxxxxxxx> wrote:
> > @@ -2866,18 +2938,12 @@ static void put_prev_task_scx(struct rq *rq, struct task_struct *p,
> >                 set_task_runnable(rq, p);
> >
> >                 /*
> > -                * Mutex-blocked donors stay queued on the runqueue under proxy
> > -                * execution, but the donor never runs as itself, proxy-exec
> > -                * walks the blocked_on chain on the next __schedule() and runs
> > -                * the lock owner in its place.
> > -                *
> > -                * Put the donor on the local DSQ directly so pick_next_task()
> > -                * can still see it. find_proxy_task() will either run the chain
> > -                * owner or deactivate the donor so the wakeup path can return it
> > -                * and let BPF make a new dispatch decision once it is unblocked.
> > +                * Mutex-blocked donors only stay queued when their BPF scheduler
> > +                * enables %SCX_OPS_ENQ_BLOCKED, so always delegate their admission.
> >                  */
> >                 if (task_is_blocked(p)) {
> > -                       scx_dispatch_enqueue(sch, rq, &rq->scx.local_dsq, p, 0);
> > +                       WARN_ON_ONCE(!(sch->ops.flags & SCX_OPS_ENQ_BLOCKED));
> > +                       scx_do_enqueue_task(rq, p, 0, -1);
> >                         goto switch_class;
> >                 }
> >
> 
> Just FYI: So in doing some testing running my priority-inversion-demo
> test in a loop with this series (rebased on 7.2-rc2), goining through
> the example schedulers in tools/sched_ext/ I hit this WARN_ON after
> running awhile with the scx_pair scheduler.
> 
> Haven't done much debugging on it yet, may have to wait until monday,
> but the splat is below.

Yeah, this is because put_prev_task_scx() uses task_is_blocked(p), and we should
use p->is_blocked instead, since task_is_blocked() can become true before the
task has actually been processed as blocked by the scheduler.

I've fixed this in my local tree, this should disappear in the next version.

Thanks!
-Andrea

> 
> thanks
> -john
> 
> [25733.271828] WARNING: kernel/sched/ext/ext.c:2945 at
> put_prev_task_scx+0x449/0x460, CPU#0: foreground/25080
> [25733.277072] CPU: 0 UID: 0 PID: 25080 Comm: foreground Not tainted
> 7.2.0-rc2-00043-g9699f4add4b0 #39 PREEMPT(full)
> [25733.286458] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.17.0-debian-1.17.0-1 04/01/2014
> [25733.295933] Sched_ext: pair (enabled+all), task: runnable_at=-798ms
> [25733.295937] RIP: 0010:put_prev_task_scx+0x449/0x460
> [25733.306251] Code: 48 8b 83 68 11 00 00 48 8b b5 10 04 00 00 48 39
> b0 98 11 00 00 0f 85 79 ff ff ff e9 65 ff ff ff 90 0f 0b 90 e9 46 fe
> ff ff 90 <0f> 0b 90 e9 b5 fd ff ff b8 02 00 00 00 e9 94 fc ff ff e8 90
> bb 2d
> [25733.322497] RSP: 0018:ffffc90011f7faa8 EFLAGS: 00010046
> [25733.325750] RAX: 0000000000000001 RBX: ffff8881b8e2db80 RCX: ffff8880bd482650
> [25733.333460] RDX: ffff8881b8e2e618 RSI: ffff8880bd482650 RDI: ffff8881073b2650
> [25733.338640] RBP: ffff8881073b22c0 R08: 0000000000000000 R09: 0000000000000000
> [25733.344710] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88800ba23000
> [25733.351179] R13: ffff8880bd4822c0 R14: ffffffff82f6a518 R15: ffffffff82f6a040
> [25733.356585] FS:  00007f9badd90780(0000) GS:ffff888234841000(0000)
> knlGS:0000000000000000
> [25733.362523] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [25733.365426] CR2: 00007f91f1e48110 CR3: 000000001113c006 CR4: 0000000000370ef0
> [25733.372285] Call Trace:
> [25733.373817]  <TASK>
> [25733.375178]  __pick_next_task+0xa8/0x180
> [25733.378968]  __schedule+0x268/0x2600
> [25733.381092]  ? mark_held_locks+0x40/0x70
> [25733.383556]  preempt_schedule_notrace+0x43/0xa0
> [25733.386311]  ? preempt_schedule_notrace_thunk+0x16/0x30
> [25733.390954]  preempt_schedule_notrace_thunk+0x16/0x30
> [25733.395476]  rcu_is_watching+0x3e/0x50
> [25733.397722]  lock_acquire+0x2c0/0x310
> [25733.401168]  ? _raw_spin_unlock_irqrestore+0x50/0x60
> [25733.404224]  schedule+0x9d/0x100
> [25733.406428]  ? schedule+0x7e/0x100
> [25733.408130]  schedule_preempt_disabled+0x18/0x30
> [25733.411008]  __mutex_lock+0x800/0x1100
> [25733.415788]  ? __start_renaming+0x5d/0x190
> [25733.419011]  ? lock_acquire+0xd9/0x310
> [25733.421518]  ? __start_renaming+0x5d/0x190
> [25733.424188]  __start_renaming+0x5d/0x190
> [25733.426676]  filename_renameat2+0x318/0x420
> [25733.429258]  ? find_held_lock+0x2b/0x80
> [25733.432581]  __x64_sys_rename+0x48/0x70
> [25733.435240]  do_syscall_64+0xf3/0x6c0
> [25733.437675]  entry_SYSCALL_64_after_hwframe+0x77/0x7f