Re: [PATCH 08/11] sched_ext: Delegate proxy donor admission to BPF schedulers

On Fri, Jul 17, 2026 at 11:16 PM John Stultz <[email protected]> wrote:
>
> On Thu, Jul 16, 2026 at 6:23 AM Andrea Righi <[email protected]> wrote:
> > @@ -3098,18 +3164,16 @@ 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.
> > +                * Mutex-blocked donors only stay queued when their BPF scheduler
> > +                * enables %SCX_OPS_ENQ_BLOCKED. The rq lock has remained held since
> > +                * scx_allow_proxy_exec(), so @p's scheduler association cannot have
> > +                * changed and @sch must be non-NULL with the flag set.
> >                  *
> > -                * 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.
> > +                * Delegate admission to the BPF scheduler.
> >                  */
> >                 if (p->is_blocked) {
> > -                       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;
> >                 }
> >
>
> So this isn't a blocker for your patches, but just as a heads up: when
> applying my sleeping owner handling changes (even just patches 4-7
> from my v30 submission[1]), I managed to trip the above WARN_ON, when
> running the test-ww_mutex driver under the scx_pair (usually right as
> scx_pair loads).
>
> [ 5818.970324] WARNING: kernel/sched/ext/ext.c:3175 at
> put_prev_task_scx+0x527/0x550, CPU#54: kworker/u261:11/30527
> [ 5818.974927] CPU: 54 UID: 0 PID: 30527 Comm: kworker/u261:11
> Tainted: G        W           7.1.0-13303-gb5ecf3c9f881 #116
> PREEMPT(full)
> [ 5818.979484] Tainted: [W]=WARN
> [ 5818.980654] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.17.0-debian-1.17.0-1 04/01/2014
> [ 5818.984225] Workqueue: test-ww_mutex test_cycle_work
> [ 5818.986199] Sched_ext: pair (enabled+all), task: runnable_at=-369ms
> [ 5818.986202] RIP: 0010:put_prev_task_scx+0x527/0x550
> [ 5818.990473] Code: 48 2b 05 34 f3 21 03 75 3c 48 83 c4 30 48 89 de
> 48 89 ef b9 ff ff ff ff 5b 31 d2 5d 41 5c 41 5d 41 5e 41 5f e9 fa f0
> ff ff 90 <0f> 0b 90 e9 b8 fe ff ff 90 0f 0b 90 e9 35 fe ff ff b8 02 00
> 00 00
> [ 5818.997428] RSP: 0018:ffffc900088dfb28 EFLAGS: 00010046
> [ 5818.999426] RAX: 0000000000000036 RBX: ffff888101258000 RCX: ffff888101d64990
> [ 5819.002113] RDX: ffff8881b9bae638 RSI: ffff888101d64990 RDI: ffff888101258390
> [ 5819.004787] RBP: ffff8881b9badb00 R08: ffff8881b9badb00 R09: 0000000000000000
> [ 5819.007967] R10: 0000000000000036 R11: ffff888120a9b030 R12: ffff888100c30000
> [ 5819.010697] R13: ffff88810d163800 R14: ffff888101258000 R15: ffff888100c30000
> [ 5819.013378] FS:  0000000000000000(0000) GS:ffff8882355c0000(0000)
> knlGS:0000000000000000
> [ 5819.016354] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 5819.018524] CR2: 00007ffe7b985348 CR3: 0000000123ec6004 CR4: 0000000000370ef0
> [ 5819.021163] Call Trace:
> [ 5819.022168]  <TASK>
> [ 5819.023010]  __schedule+0x15c4/0x2460
> [ 5819.024504]  ? find_held_lock+0x2b/0x80
> [ 5819.025981]  ? lock_release+0x191/0x310
> [ 5819.027503]  schedule+0x3d/0x130
> [ 5819.028772]  schedule_preempt_disabled+0x18/0x30
> [ 5819.030539]  __ww_mutex_lock.constprop.0+0xaea/0x19e0
> [ 5819.032492]  ? schedule_timeout+0xca/0x130
> [ 5819.034095]  ? test_cycle_work+0x15d/0x340
> [ 5819.035686]  ? ww_mutex_lock+0x3c/0xb0
> [ 5819.037094]  ww_mutex_lock+0x3c/0xb0
> [ 5819.038494]  test_cycle_work+0x15d/0x340
> [ 5819.039949]  process_one_work+0x20c/0x5e0
> [ 5819.041631]  ? lock_is_held_type+0xcd/0x130
> [ 5819.043277]  worker_thread+0x1a4/0x360
> [ 5819.044717]  ? __pfx_worker_thread+0x10/0x10
> [ 5819.046392]  kthread+0x103/0x130
> [ 5819.047650]  ? __pfx_kthread+0x10/0x10
> [ 5819.049074]  ret_from_fork+0x27c/0x340
> [ 5819.050525]  ? __pfx_kthread+0x10/0x10
> [ 5819.051990]  ret_from_fork_asm+0x1a/0x30
> [ 5819.053488]  </TASK>
> [ 5819.054371] irq event stamp: 38
> [ 5819.055583] hardirqs last  enabled at (37): [<ffffffff826a7100>]
> _raw_spin_unlock_irqrestore+0x50/0x60
> [ 5819.059054] hardirqs last disabled at (38): [<ffffffff82699205>]
> __schedule+0xb95/0x2460
> [ 5819.061998] softirqs last  enabled at (26): [<ffffffff813244d0>]
> __irq_exit_rcu+0xe0/0x150
> [ 5819.065015] softirqs last disabled at (21): [<ffffffff813244d0>]
> __irq_exit_rcu+0xe0/0x150
> [ 5819.068013] ---[ end trace 0000000000000000 ]---
>
> It seems to be coming from the proxy_resched_idle() call in the "if
> (!READ_ONCE(owner->on_rq) || owner->se.sched_delayed) {" case in
> find_proxy_task(), prior to proxy_enqueue_on_owner() calling
> block_task().
>
> I'll have to dig a bit more next week on this, as I'm not yet seeing
> whats going wrong here.

Ok, my tired theory is something like:

1) You have a task A that that is_blocked waiting on a sleeping owner
B. It gets enqueued onto that owner and waits.

2) We start scx_pair, and scx_prepare_task_sched_change() calls
sched_proxy_block_task(), which bails because !task_on_rq_queued()

3) B wakes up, and that causes us to activate_blocked_waiters(), which
re-adds A (with is_blocked still set) to the rq
   - this is problematic because now we have is_blocked tasks on the
sched_ext DSQ where its not allowed.

4) A is selected as a donor, and maybe B is sleeping again, so we call
put_prev_set_next() and hti the warning because we see A is is_blocked
when the sched_ext scheduler doesn't support it.

I'll work to prove this out a bit further next week.  I suspect we'll
need something somewhere between activate_blocked_waiters() ->
scx_do_enqueue_task() to skip enquing of is_blocked tasks when
SCX_OPS_ENQ_BLOCKED isn't set.

thanks
-john