mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH v4 0/2] sched_ext: Don't run ops.dequeue() with a DSQ lock held
@ 2026-09-17  7:52 Qiurong Fang
  2026-09-17  7:52 ` [PATCH v4 1/2] " Qiurong Fang
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Qiurong Fang @ 2026-09-17  7:52 UTC (permalink / raw)
  To: tj; +Cc: arighi, void, changwoo, sched-ext, linux-kernel

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-09-17 17:25 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-17  7:52 [PATCH v4 0/2] sched_ext: Don't run ops.dequeue() with a DSQ lock held Qiurong Fang
2026-09-17  7:52 ` [PATCH v4 1/2] " Qiurong Fang
2026-09-17  7:52 ` [PATCH v4 2/2] selftests/sched_ext: Test that ops.dequeue() can iterate the consumed DSQ Qiurong Fang
2026-09-17 17:25 ` [PATCH v4 0/2] sched_ext: Don't run ops.dequeue() with a DSQ lock held Tejun Heo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®