Re: [PATCH 10/10] sched: Allow enabling proxy exec with sched_ext

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Normal task wakeups are misidentified as blocked proxy donors in sched_ext operations (`scx_do_enqueue_task` and `wakeup_preempt_scx`), causing incorrect `SCX_ENQ_BLOCKED` flags and unconditional reschedules.
--

--- Patch [10]: [PATCH 10/10] sched: Allow enabling proxy exec with sched_ext ---
commit 3a82f8102afed9269cf69799a73d94ed44769f33
Author: Andrea Righi <[email protected]>

sched: Allow enabling proxy exec with sched_ext
    
Now that sched_ext can handle proxy donors and BPF schedulers can opt in
to blocked-donor enqueueing with SCX_OPS_ENQ_BLOCKED, remove the
!SCHED_CLASS_EXT dependency from SCHED_PROXY_EXEC and allow both options
to be enabled together.

> diff --git a/init/Kconfig b/init/Kconfig
> index 9ee6447dd454d..52376c44f60a6 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -937,8 +937,6 @@ config SCHED_PROXY_EXEC
>  	bool "Proxy Execution"
>  	# Avoid some build failures w/ PREEMPT_RT until it can be fixed
>  	depends on !PREEMPT_RT
> -	# Need to investigate how to inform sched_ext of split contexts
> -	depends on !SCHED_CLASS_EXT

[Severity: High]
Does enabling proxy exec with sched_ext here expose an issue where normal
task wakeups are misidentified as blocked proxy donors?

When tasks go to sleep without pending signals, try_to_block_task() sets
p->is_blocked = 1. When these tasks wake up, ttwu_do_activate() processes
them in this order:

kernel/sched/core.c:ttwu_do_activate() {
        ...
        activate_task(rq, p, en_flags);
        wakeup_preempt(rq, p, wake_flags);
        
        ttwu_do_wakeup(p);
        ...
}

Because activate_task() and wakeup_preempt() are called before
ttwu_do_wakeup() clears the p->is_blocked flag, p->is_blocked remains 1
during the sched_ext callbacks:

kernel/sched/ext/ext.c:scx_do_enqueue_task() {
        ...
        enq_blocked = (sch->ops.flags & SCX_OPS_ENQ_BLOCKED) &&
                      p->is_blocked;
        if (enq_blocked)
                enq_flags |= SCX_ENQ_BLOCKED;
        ...
}

And also in the wakeup path:

kernel/sched/ext/ext.c:wakeup_preempt_scx() {
        ...
        if (p->is_blocked) {
                struct scx_sched *sch = scx_task_sched(p);
                
                if (sch && (sch->ops.flags & SCX_OPS_ENQ_BLOCKED))
                        resched_curr(rq);
        }
        return;
}

If a BPF scheduler opts into SCX_OPS_ENQ_BLOCKED, will this force an
unconditional reschedule on every wakeup and skip intended preemption logic,
since it incorrectly sees all normal waking tasks as SCX_ENQ_BLOCKED?

Would it be safer for sched_ext to use task_is_blocked(p) (which evaluates
!!p->blocked_on) rather than p->is_blocked to correctly identify actual
blocked proxy donors?

>  	# Not particularly useful until we get to multi-rq proxying
>  	depends on EXPERT
>  	help

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=10