[PATCH v4 0/2] sched_ext: Don't run ops.dequeue() with a DSQ lock held

Qiurong Fang posted 2 patches 1 week ago
kernel/sched/ext/ext.c                        | 44 ++++++------
kernel/sched/ext/internal.h                   |  3 +-
kernel/sched/ext/sub.c                        | 10 +--
tools/testing/selftests/sched_ext/Makefile    |  1 +
.../selftests/sched_ext/dequeue_iter.bpf.c    | 73 +++++++++++++++
.../selftests/sched_ext/dequeue_iter.c        | 79 +++++++++++++++
6 files changed, 181 insertions(+), 29 deletions(-)
create mode 100644 tools/testing/selftests/sched_ext/dequeue_iter.bpf.c
create mode 100644 tools/testing/selftests/sched_ext/dequeue_iter.c
[PATCH v4 0/2] sched_ext: Don't run ops.dequeue() with a DSQ lock held
Posted by Qiurong Fang 1 week ago
From: fangqiurong <fangqiurong@kylinos.cn>

The consume and move paths invoke ops.dequeue() with the source user
DSQ's lock held, self-deadlocking any BPF scheduler which locks the
same DSQ from ops.dequeue(). Move the invocations after the DSQ unlock.

v3 -> v4:
- Reword the terminal-branch comment: the callback runs after
  @dsq->lock is dropped, not "unlocked" - the rq lock is held on every
  path (Tejun Heo)
- Drop the unused @src_dsq parameter of scx_move_local_task_to_local_dsq()
  (Tejun Heo)
- Fix the dangling "there" in the commit message (Tejun Heo)
- selftest: reword the header comment and poll from run() directly
  instead of from a worker thread (Tejun Heo)

v2 -> v3:
- Restrict the deadlock description to the two user DSQ paths; keep
  the global/bypass move for the shared DSQ lockdep class (Tejun Heo)
- Drop the ordering sentence and the doc change until the DISPATCHING
  reenq hole is fixed (Tejun Heo)
- Open-code the ops.dequeue() invocations and drop call_task_dequeue()
  (Tejun Heo)
- Drop the __scx_move_local_task_to_local_dsq() split; unlock @src_dsq
  right after unlinking (Tejun Heo)
- selftest: add ops.select_cpu(), record UEI and check SCX_EXIT_UNREG,
  fix the watchdog wording (Tejun Heo)
- Set ops.timeout_ms to the suite-standard 1000U
- Add Cc: stable # v7.1+ (Tejun Heo)

v1 -> v2:
- Drop the claim that ops.dequeue() may run after the task has
  re-entered custody: SCX_OPSS_DISPATCHING is held across the callback
  on the global/bypass path and @p's rq lock is held across the
  callback on the user-DSQ-to-local paths (Andrea Righi)
- Add a selftest whose ops.dequeue() iterates the source user DSQ
  (Andrea Righi)

Patch 1 carries Andrea's Acked-by from the v1 review.
Link: https://lore.kernel.org/all/20260916070753.3343113-1-fangqiurong@kylinos.cn/

fangqiurong (2):
  sched_ext: Don't run ops.dequeue() with a DSQ lock held
  selftests/sched_ext: Test that ops.dequeue() can iterate the consumed
    DSQ

 kernel/sched/ext/ext.c                        | 44 ++++++------
 kernel/sched/ext/internal.h                   |  3 +-
 kernel/sched/ext/sub.c                        | 10 +--
 tools/testing/selftests/sched_ext/Makefile    |  1 +
 .../selftests/sched_ext/dequeue_iter.bpf.c    | 73 +++++++++++++++
 .../selftests/sched_ext/dequeue_iter.c        | 79 +++++++++++++++
 6 files changed, 181 insertions(+), 29 deletions(-)
 create mode 100644 tools/testing/selftests/sched_ext/dequeue_iter.bpf.c
 create mode 100644 tools/testing/selftests/sched_ext/dequeue_iter.c

--
2.43.0
Re: [PATCH v4 0/2] sched_ext: Don't run ops.dequeue() with a DSQ lock held
Posted by Tejun Heo 1 week ago
On Thu, Sep 17, 2026 at 03:52:40PM +0800, Qiurong Fang wrote:
> fangqiurong (2):
>   sched_ext: Don't run ops.dequeue() with a DSQ lock held
>   selftests/sched_ext: Test that ops.dequeue() can iterate the consumed
>     DSQ

Applied 1-2 to sched_ext/for-7.3-fixes.

Thanks.

--
tejun