[BUG] sched_ext: ops.sub_ecaps_updated() dispatch context is set up on the wrong CPU under core scheduling

[David Carlier <devnexen@gmail.com>]

Hello,

scx_process_sync_ecaps() looks like a missed instance of the bug class
3dd52416e44a ("sched_ext: Fix this_rq() assumptions in dispatch kfuncs")
fixed: before invoking ops.sub_ecaps_updated() it does

		struct scx_dsp_ctx *dspc = &pcpu->dsp_ctx;

		dspc->rq = rq;

where @pcpu is the *target* CPU's context (recovered from the llist node),
while the dispatch kfuncs resolve theirs with this_cpu_ptr(sch->pcpu).
Identical until dispatch_core_pick() started running balance_one() for
sibling rqs - now a sync processed by a sibling calls the op with the
executing CPU's dsp_ctx.rq unset.

Nothing ever writes a sub's dsp_ctx.rq on a CPU before the first
scx_bpf_sub_dispatch() there, so it is NULL at attach time - exactly when
the initial cap-grant notifications fire. If the op then calls e.g.
scx_bpf_dsq_move_to_local() (it has SCX_KF_ALLOW_DISPATCH) on a non-empty
DSQ, scx_consume_dispatch_q(sch, NULL, ...) reaches
task_can_run_on_remote_rq() -> cpu_of(NULL) and oopses in the pick path.
A leftover rq from an earlier dispatch instead consumes toward the wrong
rq.

Fix seems to be a one-liner matching scx_dispatch_sched():

	-		struct scx_dsp_ctx *dspc = &pcpu->dsp_ctx;
	+		struct scx_dsp_ctx *dspc =
	+			&this_cpu_ptr(pcpu->sch->pcpu)->dsp_ctx;

with Fixes: b81a6c018cde ("sched_ext: Add sub_ecaps_updated()
effective-cap change notifier"). Happy to send a patch if nobody is on it,
or feel free to just fix it directly.

Cheers !