Re: [PATCH 11/15] sched_ext: Split curr|donor references properly

[email protected] Tue, 28 Jul 2026 16:25:17 +0000
Newsgroups dev.linux.lists.sched-ext
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:
- [Medium] Documentation incorrectly claims blocked donors bypass ops.runni=
ng()/ops.stopping(), contradicting the implementation
--

--- Patch [11]: [PATCH 11/15] sched_ext: Split curr|donor references proper=
ly ---
commit 5cd9f3cfe50f459bfe5f1a7d7f7b8af97933ae95
Author: Andrea Righi <[email protected]>

sched_ext: Split curr|donor references properly

This commit updates sched_ext to use rq->donor as the scheduling context
under proxy execution instead of rq->curr. It updates references in various
scheduler hooks and BPF kfuncs, and extends scx_dump_state() to report both
contexts.

> diff --git a/Documentation/scheduler/sched-ext.rst b/Documentation/schedu=
ler/sched-ext.rst
> index ad2fff3c05937..db1ef89ed8f2a 100644
> --- a/Documentation/scheduler/sched-ext.rst
> +++ b/Documentation/scheduler/sched-ext.rst
> @@ -487,6 +487,12 @@ and edge cases, to name a few examples:
>    class, in which case it will exit the tick-dispatch loop even though i=
t is runnable
>    and has a non-zero slice.
> =20
> +* Under proxy execution, sched_ext continues to observe the donor as the=
 current
> +  scheduling context. A blocked donor does not enter an ``ops.running()`=
` /
> +  ``ops.stopping()`` session because it does not execute itself, and the=
 lock
> +  owner executing on its behalf is intentionally not reported through th=
ese
> +  callbacks.

[Severity: Medium]
Is this documentation accurate regarding the implementation?

The documentation states that a blocked donor bypasses ops.running() and
ops.stopping(). However, the implementation invokes ops.running() via
scx_proxy_donor_start() when the proxy execution context is resolved, and
ops.stopping() is invoked via put_prev_task().

Could this contradiction mislead BPF scheduler authors into believing the
task lifecycle state machine is bypassed for blocked donors, when in fact
the running session is maintained?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260728154425.1549=
[email protected]?part=3D11