Re: [BUG] sched_ext: sub-scheduler kfuncs use struct scx_sched beyond the RCU read side under sleepable ops

[Tejun Heo <tj@kernel.org>]

Hello, Guikun.

On Sat, Oct 24, 2026 at 03:47:07PM +0800, Guikun Yang wrote:
> The four sub-scheduler kfuncs scx_bpf_sub_grant(), scx_bpf_sub_revoke(),
> scx_bpf_sub_caps() and scx_bpf_sub_kill_bstr() obtain the child
> scheduler through scx_find_sub_sched(), which is an
> rhashtable_lookup() call.  rhashtable_lookup() is the _fast variant:
> it takes and releases the RCU read lock internally, so the returned
> struct scx_sched * is only valid inside the caller's own RCU read-side
> critical section.

There's no use-after-free here.

rhashtable_lookup() isn't the _fast variant. It requires the caller to
be in an RCU read-side critical section. rhashtable_lookup_fast() is the
one that wraps itself in rcu_read_lock()/rcu_read_unlock().

> The kfuncs themselves only take guard(irqsave)() (sub.c:2323).  They do
> not hold an RCU read lock and take no reference on the scheduler, yet
> they use the returned pointer for their whole body, for example in
> scx_bpf_sub_grant():

scx_bpf_sub_grant(), scx_bpf_sub_revoke() and scx_bpf_sub_caps() do
guard(irqsave)() before the lookup, and the lookup and every use of the
child happen inside that IRQ-disabled region. scx_bpf_sub_kill_bstr()
takes guard(rcu)() explicitly.

Since v5.0, a region with IRQs disabled is an RCU read-side critical
section, and synchronize_rcu(), synchronize_rcu_expedited() and
call_rcu()/queue_rcu_work() wait for it (see the comment above
synchronize_rcu() in kernel/rcu/tree.c). Whether the sleepable program
holds an RCU lock of its own doesn't matter.

> There is no synchronize_rcu_tasks_trace(), call_rcu_tasks_trace() or
> kfree_rcu_tasks anywhere under kernel/sched/ext/.  A normal RCU
> grace period does not wait for rcu_read_lock_trace() sections, so a
> sleepable op running inside the teardown window keeps using the freed
> scheduler object.

scx_unlink_sched() removes the sched from scx_sched_hash before the last
reference is dropped, and scx_kobj_release() frees it through
queue_rcu_work(). So the grace period before the free waits for any
kfunc that found the sched in the hash.

Thanks.

--
tejun