summaryrefslogtreecommitdiff
path: root/kernel
diff options
context:
space:
mode:
authorTejun Heo <tj@kernel.org>2026-08-14 14:56:56 -1000
committerTejun Heo <tj@kernel.org>2026-08-15 00:07:42 -1000
commite0253dd04beb03e79477c5ef4768b11135687206 (patch)
tree55359b3fef69df997cb975aa05d17efb730b07d2 /kernel
parent524ab50763af33d65e6e042cf7034cd8f82d437b (diff)
sched_ext: Keep kick_sync waiting on the rq's own CPU
kick_sync_wait_bal_cb() assumes it runs on the rq's CPU from the __schedule() tail: the snapshots it compares against live in that CPU's percpu area and the busy-wait runs with the rq lock dropped and IRQs enabled. However, dispatch can now drop the rq lock while the callback sits queued, and rq lock takers in that window (the sched class change paths, the scx task iterator) flush pending balance callbacks on release, running the callback on a foreign CPU. Such a run compares against unrelated snapshots and can deadlock when the executing CPU is itself a wait target. Bail on a foreign CPU and leave the wait state alone. The wait only observes progress that the resched kicks already guarantee and the rq's next wait picks up the stale cpus_to_sync bits. Fixes: 4c95380701f5 ("sched/ext: Fold balance_scx() into pick_task_scx()") Cc: stable@vger.kernel.org # v6.19+ Signed-off-by: Tejun Heo <tj@kernel.org>
Diffstat (limited to 'kernel')
-rw-r--r--kernel/sched/ext/ext.c19
1 files changed, 17 insertions, 2 deletions
diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
index 950d98508463..743eba10650a 100644
--- a/kernel/sched/ext/ext.c
+++ b/kernel/sched/ext/ext.c
@@ -3269,12 +3269,27 @@ switch_class:
static void kick_sync_wait_bal_cb(struct rq *rq)
{
- struct scx_kick_syncs __rcu *ks = __this_cpu_read(scx_kick_syncs);
- unsigned long *ksyncs = rcu_dereference_sched(ks)->syncs;
+ struct scx_kick_syncs __rcu *ks;
+ unsigned long *ksyncs;
bool waited;
s32 cpu;
/*
+ * This callback is queued and normally flushed within @rq's own
+ * scheduling pass. However, dispatch can drop the rq lock while it sits
+ * queued, and lock takers in that window (the sched class change paths,
+ * the scx task iterator) flush pending balance callbacks on release,
+ * running this one on a foreign CPU whose snapshots are unrelated. The
+ * kicked CPUs are already on their way to advance the kick_syncs being
+ * waited on. Don't get in the way.
+ */
+ if (unlikely(cpu_of(rq) != smp_processor_id()))
+ return;
+
+ ks = __this_cpu_read(scx_kick_syncs);
+ ksyncs = rcu_dereference_sched(ks)->syncs;
+
+ /*
* Drop rq lock and enable IRQs while waiting. IRQs must be enabled
* — a target CPU may be waiting for us to process an IPI (e.g. TLB
* flush) while we wait for its kick_sync to advance.