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

[Qiurong Fang]

From: fangqiurong <fangqiurong@xxxxxxxxxx>

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

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/aqkQ1MtqtqnS0wUs@gpd4/

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

 Documentation/scheduler/sched-ext.rst         |  4 +-
 kernel/sched/ext/ext.c                        | 67 ++++++++++---
 tools/testing/selftests/sched_ext/Makefile    |  1 +
 .../selftests/sched_ext/dequeue_iter.bpf.c    | 65 +++++++++++++
 .../selftests/sched_ext/dequeue_iter.c        | 94 +++++++++++++++++++
 5 files changed, 216 insertions(+), 15 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