Re: [PATCH v4 sched_ext/for-7.3 34/40] sched_ext: Authorize remote-move inserts against the placing scheduler

On Wed, 08 Jul 2026 22:04:44 +0000, [email protected] wrote:
> This is a pre-existing issue, but does passing the placing scheduler
> during local moves cause issues with ops.dequeue?

The combination can't materialize: call_task_dequeue() no-ops unless
SCX_TASK_IN_CUSTODY is set, custody is only entered for tasks placed on a
user DSQ after an scx_task_on_sched() ownership check, and the one path
where placer != owner (remote bypass drain) runs with custody already
clear. That said, v5 adds a WARN_ON_ONCE to the per-task op macros
asserting @sch is the task's owner, with the two intentional non-owner
sites dispatching explicitly, so any future conflation surfaces instead
of hiding.

> If the placer passes invalid enq_flags or an invalid DSQ ID to a
> built-in DSQ, scx_dispatch_enqueue() triggers scx_error(sch, "cannot use
> vtime..."). For remote moves, sch here is the owner.

A remote re-activation always inserts into the local (or reject) DSQ, so
the builtin-DSQ error branches aren't reachable from a placer move - they
fire on a scheduler's own dispatches.

> should the error attribution (and events like SCX_EV_SUB_FORCED_ADMIT)
> use asch instead of sch so the descendant scheduler isn't unfairly
> aborted when an ancestor lacks capabilities?

scx_local_or_reject_dsq() records no error and aborts nothing - the
missing-caps branch either force-admits or diverts to the reject DSQ. The
only owner-vs-placer @sch use is the FORCED_ADMIT event counter, which is
cosmetic. May sync it to @asch later.

Thanks.

-- 
tejun