diff options
| author | Tejun Heo <tj@kernel.org> | 2026-07-13 22:18:44 -1000 |
|---|---|---|
| committer | Tejun Heo <tj@kernel.org> | 2026-07-13 22:18:44 -1000 |
| commit | f2c9f5155ba8ee798e95b7a656d600cc2de687a0 (patch) | |
| tree | 10f9c60b64149d0db874c8ab0282b3ea364ee663 /tools/perf/scripts/python | |
| parent | 6ea3be36808100336dffb4b04a6e5a483a26a649 (diff) | |
sched_ext: Authorize remote-move inserts against the placing scheduler
scx_local_or_reject_dsq() authorizes a local-DSQ insert against the caps
of the scheduler doing the insert. On the consume/dispatch paths that is
the scheduler running balance_one(), passed down through
scx_consume_dispatch_q() and move_local_task_to_local_dsq(), so the check
is correct.
The remote-move path loses it. move_remote_task_to_local_dsq()
re-activates @p on the destination rq through enqueue_task_scx(), which
reconstructs the scheduler from the task, i.e. @p's owner. When an
ancestor places a descendant's task - e.g. draining a bypassed
sub-scheduler - the owner is a sub-scheduler of the placer, so
authorizing against the owner checks a narrower cap set and can
spuriously reject a task the placer is entitled to run.
Carry the placing scheduler across the activate_task() boundary the same
way enq_flags already are, via a per-rq field set only for the duration
of the re-activation, and have scx_local_or_reject_dsq() authorize
against it. The placer's caps are a superset of the owner's, so this
admits what the placer may run and keeps rejecting what it may not.
v2: Document @sch in move_remote_task_to_local_dsq()'s kerneldoc. (Andrea)
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Andrea Righi <arighi@nvidia.com>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions
