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