From: sashiko-bot@kernel.org
To: "Kang Chen" <k.chen@smail.nju.edu.cn>
Cc: sched-ext@lists.linux.dev, bpf@vger.kernel.org
Subject: Re: [PATCH] sched_ext: make DSQ iterator stay drained after NULL
Date: Tue, 10 Nov 2026 13:01:09 +0000 [thread overview]
Message-ID: <sashiko-outbox-207066@kernel.org> (raw)
In-Reply-To: <20261110125113.2935742-1-k.chen@smail.nju.edu.cn>
Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [High] sched_ext: recursive dsq->lock deadlock via
bpf_iter_scx_dsq_next() in tracing [1]
--
commit 892356944fb79fb9f40ab2f24779b6976bd4ec25
Author: Kang Chen <k.chen@smail.nju.edu.cn>
sched_ext: make DSQ iterator stay drained after NULL
This commit records a drained flag in the DSQ iterator cursor once
nldsq_cursor_next_task() returns NULL so subsequent calls to
bpf_iter_scx_dsq_next() continue returning NULL.
> diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> index ebdf7b91f9d37..f2bfd43d75526 100644
> --- a/kernel/sched/ext/ext.c
> +++ b/kernel/sched/ext/ext.c
[ ... ]
> @@ -11028,13 +11030,24 @@ __bpf_kfunc int bpf_iter_scx_dsq_new(struct bpf_iter_scx_dsq *it, u64 dsq_id,
> __bpf_kfunc struct task_struct *bpf_iter_scx_dsq_next(struct bpf_iter_scx_dsq *it)
> {
> struct bpf_iter_scx_dsq_kern *kit = (void *)it;
> + struct task_struct *p;
>
> - if (!kit->dsq)
> + if (!kit->dsq || (kit->cursor.flags & __SCX_DSQ_ITER_DRAINED))
> return NULL;
>
> guard(raw_spinlock_irqsave)(&kit->dsq->lock);
[Severity: High]
This problem wasn't introduced by this patch, but can bpf_iter_scx_dsq_next()
and bpf_iter_scx_dsq_destroy() deadlock [1] on kit->dsq->lock when
called from a BPF tracing program?
The DSQ iterator kfuncs are registered in scx_kfunc_ids_any and are not
listed in scx_kfunc_ids_no_tracing, so scx_kfunc_context_filter() allows
BPF_PROG_TYPE_TRACING programs to call them. If a tracing program runs
while the current CPU already holds the same user DSQ's lock, iterating that
DSQ attempts to acquire kit->dsq->lock recursively on the same CPU:
scx_dispatch_enqueue()
raw_spin_lock(&dsq->lock)
...
scx_error()
trace_sched_ext_exit()
<BPF tracing prog>
bpf_iter_scx_dsq_next()
raw_spin_lock_irqsave(&kit->dsq->lock) <-- spins forever
Adding the DSQ iterator kfuncs to scx_kfunc_ids_no_tracing would prevent
tracing programs from calling them.
[1] https://sashiko.dev/#/bug/linux-243627bf-8f5e-401e-a2af-0b6c5d9b3088
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261110125113.2935742-1-k.chen@smail.nju.edu.cn?part=1
next prev parent reply other threads:[~2026-11-10 13:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 12:51 [PATCH] sched_ext: make DSQ iterator stay drained after NULL Kang Chen
2026-11-10 13:01 ` sashiko-bot [this message]
2026-11-10 19:37 ` 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=sashiko-outbox-207066@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=k.chen@smail.nju.edu.cn \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sched-ext@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.