All of lore.kernel.org
 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 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.