From: Tejun Heo <tj@kernel.org>
To: David Vernet <void@manifault.com>,
Andrea Righi <arighi@nvidia.com>,
Changwoo Min <changwoo@igalia.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Emil Tsalapatis <emil@etsalapatis.com>,
sched-ext@lists.linux.dev, linux-kernel@vger.kernel.org,
Tejun Heo <tj@kernel.org>,
stable@vger.kernel.org
Subject: [PATCH 1/3] sched_ext: Keep kick_sync waiting on the rq's own CPU
Date: Fri, 14 Aug 2026 15:05:30 -1000 [thread overview]
Message-ID: <20260815010532.3663253-2-tj@kernel.org> (raw)
In-Reply-To: <20260815010532.3663253-1-tj@kernel.org>
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>
---
kernel/sched/ext/ext.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
index 2adf2bde0cb1..4867517b71a4 100644
--- a/kernel/sched/ext/ext.c
+++ b/kernel/sched/ext/ext.c
@@ -3269,11 +3269,26 @@ static void put_prev_task_scx(struct rq *rq, struct task_struct *p,
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
--
2.55.0
next prev parent reply other threads:[~2026-08-15 1:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-15 1:05 [PATCHSET sched_ext/for-7.3] sched_ext: Dispatch path follow-ups Tejun Heo
2026-08-15 1:05 ` Tejun Heo [this message]
2026-08-15 1:05 ` [PATCH 2/3] sched_ext: Drop the stale keep_prev fixup in dispatch_pick() Tejun Heo
2026-08-15 1:05 ` [PATCH 3/3] sched_ext: Rename balance-era identifiers to dispatch terms Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260815010532.3663253-2-tj@kernel.org \
--to=tj@kernel.org \
--cc=arighi@nvidia.com \
--cc=changwoo@igalia.com \
--cc=emil@etsalapatis.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=sched-ext@lists.linux.dev \
--cc=stable@vger.kernel.org \
--cc=void@manifault.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox