[PATCH 0/4] sched_ext: fix three unreliable selftests and compat kfunc signature

[PATCH 0/4] sched_ext: fix three unreliable selftests and compat kfunc signature

[zhidao su]

Three selftests added in c50dcf533149 ("selftests/sched_ext: Add tests
for SCX_ENQ_IMMED and scx_bpf_dsq_reenq()") have design flaws that
prevent them from reliably triggering the kernel behavior they were
written to verify.  This series fixes all three, plus a related
compat.bpf.h signature bug.

- Patch 1: compat.bpf.h declares scx_bpf_dsq_reenq___compat with an
  explicit aux__prog parameter, but scx_bpf_dsq_reenq() is a
  KF_IMPLICIT_ARGS kfunc, so the BPF-side declaration must NOT include
  the implicit parameter.

- Patch 2 (enq_immed): when the IMMED slow path fires, reenqueued tasks
  were re-inserted into CPU 0's local DSQ, immediately re-triggering
  the slow path and creating an infinite cycle that hits
  SCX_REENQ_LOCAL_MAX_REPEAT (256).  Fix: redirect reenqueued tasks to
  SCX_DSQ_GLOBAL.

- Patch 3 (dsq_reenq): dispatch consumed USER_DSQ directly, racing with
  the 5 ms BPF timer.  By the time the timer fired, USER_DSQ was empty
  and scx_bpf_dsq_reenq() found nothing to reenqueue.  Fix: two-DSQ
  design where USER_DSQ is never touched by dispatch.

- Patch 4 (consume_immed): workers were spread across all CPUs, so
  USER_DSQ usually had only one task and dsq->nr never exceeded 1.  Fix:
  pin all workers to CPU 0 via CPU affinity so USER_DSQ always has
  backlog; add dispatch loop to accumulate 2+ tasks and reliably trigger
  the IMMED slow path.

All three tests verified with virtme-ng (PASSED: 30, FAILED: 0 across
the full sched_ext selftest suite).

zhidao su (4):
  tools/sched_ext: compat.bpf.h: fix scx_bpf_dsq_reenq___compat
    signature
  selftests/sched_ext: enq_immed: fix IMMED reenqueue livelock
  selftests/sched_ext: dsq_reenq: fix reliability with two-DSQ design
  selftests/sched_ext: consume_immed: fix reliability with CPU affinity

 tools/sched_ext/include/scx/compat.bpf.h      |  4 +-
 .../selftests/sched_ext/consume_immed.bpf.c   | 19 ++++++--
 .../selftests/sched_ext/consume_immed.c       | 15 +++++--
 .../selftests/sched_ext/dsq_reenq.bpf.c       | 45 ++++++++++++++-----
 .../selftests/sched_ext/enq_immed.bpf.c       | 10 ++++-
 5 files changed, 73 insertions(+), 20 deletions(-)

-- 
2.43.0

[PATCH 1/4] tools/sched_ext: compat.bpf.h: fix scx_bpf_dsq_reenq___compat signature

[zhidao su]

scx_bpf_dsq_reenq() is declared with KF_IMPLICIT_ARGS in the kernel BTF,
which means the BPF verifier automatically injects the
struct bpf_prog_aux *aux parameter.  The BPF-side weak symbol declaration
must NOT include the implicit parameter.

The previous declaration included an explicit aux__prog parameter, which
caused BPF programs calling scx_bpf_dsq_reenq() through the compat macro
to fail verification on kernels where the kfunc is available.

Fix the declaration to match the calling convention expected by the
verifier (2 parameters: dsq_id and reenq_flags).

Fixes: c50dcf533149 ("selftests/sched_ext: Add tests for SCX_ENQ_IMMED and scx_bpf_dsq_reenq()")
Signed-off-by: zhidao su <suzhidao@xiaomi.com>
---
 tools/sched_ext/include/scx/compat.bpf.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/sched_ext/include/scx/compat.bpf.h b/tools/sched_ext/include/scx/compat.bpf.h
index 654b566bd94a..6fbacc909b8b 100644
--- a/tools/sched_ext/include/scx/compat.bpf.h
+++ b/tools/sched_ext/include/scx/compat.bpf.h
@@ -405,7 +405,7 @@ static inline void scx_bpf_reenqueue_local(void)
  * v6.20: New scx_bpf_dsq_reenq() that allows re-enqueues on more DSQs. This
  * will eventually deprecate scx_bpf_reenqueue_local().
  */
-void scx_bpf_dsq_reenq___compat(u64 dsq_id, u64 reenq_flags, const struct bpf_prog_aux *aux__prog) __ksym __weak;
+void scx_bpf_dsq_reenq___compat(u64 dsq_id, u64 reenq_flags) __ksym __weak;
 
 static inline bool __COMPAT_has_generic_reenq(void)
 {
@@ -415,7 +415,7 @@ static inline bool __COMPAT_has_generic_reenq(void)
 static inline void scx_bpf_dsq_reenq(u64 dsq_id, u64 reenq_flags)
 {
 	if (bpf_ksym_exists(scx_bpf_dsq_reenq___compat))
-		scx_bpf_dsq_reenq___compat(dsq_id, reenq_flags, NULL);
+		scx_bpf_dsq_reenq___compat(dsq_id, reenq_flags);
 	else if (dsq_id == SCX_DSQ_LOCAL && reenq_flags == 0)
 		scx_bpf_reenqueue_local();
 	else
-- 
2.43.0

[PATCH 2/4] selftests/sched_ext: enq_immed: fix IMMED reenqueue livelock

[zhidao su]

When the IMMED slow path fires, ops.enqueue() is called with SCX_ENQ_REENQ
and SCX_TASK_REENQ_IMMED set.  The original code fell through to the
normal enqueue path, which re-inserted the task into SCX_DSQ_LOCAL_ON|0
(CPU 0's local DSQ) with SCX_ENQ_IMMED still present.

This immediately re-triggered the slow path, which called ops.enqueue()
again, creating an infinite cycle.  After SCX_REENQ_LOCAL_MAX_REPEAT (256)
iterations the kernel aborts with BUG_ON.

Additionally, the dispatch handler consumed from SCX_DSQ_GLOBAL even
though no tasks were ever placed there, so it was a no-op.

Fix by redirecting reenqueued tasks to SCX_DSQ_GLOBAL so they escape
the CPU 0 local DSQ orbit, breaking the cycle.  Remove the now-pointless
scx_bpf_dsq_move_to_local(SCX_DSQ_GLOBAL) call from dispatch.

Fixes: c50dcf533149 ("selftests/sched_ext: Add tests for SCX_ENQ_IMMED and scx_bpf_dsq_reenq()")
Signed-off-by: zhidao su <suzhidao@xiaomi.com>
---
 tools/testing/selftests/sched_ext/enq_immed.bpf.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/sched_ext/enq_immed.bpf.c b/tools/testing/selftests/sched_ext/enq_immed.bpf.c
index 805dd0256218..a006f07334ef 100644
--- a/tools/testing/selftests/sched_ext/enq_immed.bpf.c
+++ b/tools/testing/selftests/sched_ext/enq_immed.bpf.c
@@ -35,6 +35,15 @@ void BPF_STRUCT_OPS(enq_immed_enqueue, struct task_struct *p, u64 enq_flags)
 
 		if (reason == SCX_TASK_REENQ_IMMED)
 			__sync_fetch_and_add(&nr_immed_reenq, 1);
+
+		/*
+		 * The slow path re-enqueues IMMED tasks that couldn't run
+		 * immediately.  Avoid re-pinning them to CPU 0's local DSQ,
+		 * which would trigger another slow-path cycle (livelock).
+		 * Send them to the global DSQ instead.
+		 */
+		scx_bpf_dsq_insert(p, SCX_DSQ_GLOBAL, SCX_SLICE_DFL, enq_flags);
+		return;
 	}
 
 	if (p->tgid == (pid_t)test_tgid)
@@ -47,7 +56,6 @@ void BPF_STRUCT_OPS(enq_immed_enqueue, struct task_struct *p, u64 enq_flags)
 
 void BPF_STRUCT_OPS(enq_immed_dispatch, s32 cpu, struct task_struct *prev)
 {
-	scx_bpf_dsq_move_to_local(SCX_DSQ_GLOBAL, 0);
 }
 
 void BPF_STRUCT_OPS(enq_immed_exit, struct scx_exit_info *ei)
-- 
2.43.0

[PATCH 3/4] selftests/sched_ext: dsq_reenq: fix reliability with two-DSQ design

[zhidao su]

The original test used a single USER_DSQ for both holding tasks and
triggering scx_bpf_dsq_reenq().  ops.dispatch() consumed directly from
USER_DSQ, which raced with the 5 ms BPF timer: by the time the timer
fired, dispatch had already drained USER_DSQ, so scx_bpf_dsq_reenq()
found no tasks to reenqueue and nr_reenq_kfunc remained zero.

Fix with a two-DSQ design:
- USER_DSQ: tasks land here on initial enqueue; ops.dispatch() never
  consumes from it, so tasks accumulate and the timer always finds them.
- RUN_DSQ: reenqueued tasks (SCX_ENQ_REENQ path) land here; dispatch
  consumes from RUN_DSQ so tasks can run.

This guarantees scx_bpf_dsq_reenq() always observes tasks in USER_DSQ
and nr_reenq_kfunc is reliably incremented every timer tick.

Fixes: c50dcf533149 ("selftests/sched_ext: Add tests for SCX_ENQ_IMMED and scx_bpf_dsq_reenq()")
Signed-off-by: zhidao su <suzhidao@xiaomi.com>
---
 .../selftests/sched_ext/dsq_reenq.bpf.c       | 45 ++++++++++++++-----
 1 file changed, 35 insertions(+), 10 deletions(-)

diff --git a/tools/testing/selftests/sched_ext/dsq_reenq.bpf.c b/tools/testing/selftests/sched_ext/dsq_reenq.bpf.c
index 750bb10508df..ccce75a99d8a 100644
--- a/tools/testing/selftests/sched_ext/dsq_reenq.bpf.c
+++ b/tools/testing/selftests/sched_ext/dsq_reenq.bpf.c
@@ -2,9 +2,15 @@
 /*
  * Validate scx_bpf_dsq_reenq() semantics on user DSQs.
  *
- * A BPF timer periodically calls scx_bpf_dsq_reenq() on a user DSQ,
- * causing tasks to be re-enqueued through ops.enqueue() with SCX_ENQ_REENQ
- * set and SCX_TASK_REENQ_KFUNC recorded in p->scx.flags.
+ * Worker tasks are placed into USER_DSQ.  ops.dispatch() does NOT consume
+ * from USER_DSQ directly, so tasks accumulate there between timer ticks.
+ * A BPF timer fires every 5 ms and calls scx_bpf_dsq_reenq(USER_DSQ, 0),
+ * which re-enqueues every task in USER_DSQ through ops.enqueue() with
+ * SCX_ENQ_REENQ set and SCX_TASK_REENQ_KFUNC in p->scx.flags.
+ *
+ * Reenqueued tasks are placed into RUN_DSQ so ops.dispatch() can pick them
+ * up and run them.  This two-queue design guarantees tasks remain in
+ * USER_DSQ long enough for the timer to observe them.
  *
  * The test verifies:
  *  - scx_bpf_dsq_reenq() triggers ops.enqueue() with SCX_ENQ_REENQ
@@ -18,7 +24,13 @@ char _license[] SEC("license") = "GPL";
 
 UEI_DEFINE(uei);
 
+/*
+ * USER_DSQ: tasks sit here between timer ticks so scx_bpf_dsq_reenq()
+ *           can observe and re-enqueue them.
+ * RUN_DSQ:  tasks land here after reenqueue and are consumed by dispatch.
+ */
 #define USER_DSQ	0
+#define RUN_DSQ		1
 
 /*
  * SCX_TASK_REENQ_REASON_MASK and SCX_TASK_REENQ_KFUNC are exported via
@@ -58,27 +70,36 @@ static int reenq_timerfn(void *map, int *key, struct bpf_timer *timer)
 
 void BPF_STRUCT_OPS(dsq_reenq_enqueue, struct task_struct *p, u64 enq_flags)
 {
-	/*
-	 * If this is a kfunc-triggered reenqueue, verify that
-	 * SCX_TASK_REENQ_KFUNC is recorded in p->scx.flags.
-	 */
 	if (enq_flags & SCX_ENQ_REENQ) {
 		u32 reason = p->scx.flags & SCX_TASK_REENQ_REASON_MASK;
 
 		if (reason == SCX_TASK_REENQ_KFUNC)
 			__sync_fetch_and_add(&nr_reenq_kfunc, 1);
+
+		/*
+		 * Reenqueued tasks go to RUN_DSQ so dispatch() can run them.
+		 * Keeping them in USER_DSQ would cause the timer to reenqueue
+		 * them again endlessly without ever running.
+		 */
+		scx_bpf_dsq_insert(p, RUN_DSQ, SCX_SLICE_DFL, enq_flags);
+		return;
 	}
 
 	/*
-	 * Always dispatch to USER_DSQ so the timer can reenqueue tasks again
-	 * on the next tick.
+	 * Non-reenqueue path: place the task in USER_DSQ.  ops.dispatch()
+	 * does not consume USER_DSQ directly, so tasks sit here until the
+	 * timer fires and calls scx_bpf_dsq_reenq(USER_DSQ, 0).
 	 */
 	scx_bpf_dsq_insert(p, USER_DSQ, SCX_SLICE_DFL, enq_flags);
 }
 
 void BPF_STRUCT_OPS(dsq_reenq_dispatch, s32 cpu, struct task_struct *prev)
 {
-	scx_bpf_dsq_move_to_local(USER_DSQ, 0);
+	/*
+	 * Only consume from RUN_DSQ (tasks that have been through the
+	 * reenqueue path).  USER_DSQ is deliberately left for the timer.
+	 */
+	scx_bpf_dsq_move_to_local(RUN_DSQ, 0);
 }
 
 s32 BPF_STRUCT_OPS_SLEEPABLE(dsq_reenq_init)
@@ -91,6 +112,10 @@ s32 BPF_STRUCT_OPS_SLEEPABLE(dsq_reenq_init)
 	if (ret)
 		return ret;
 
+	ret = scx_bpf_create_dsq(RUN_DSQ, -1);
+	if (ret)
+		return ret;
+
 	if (!__COMPAT_has_generic_reenq()) {
 		scx_bpf_error("scx_bpf_dsq_reenq() not available");
 		return -EOPNOTSUPP;
-- 
2.43.0

[PATCH 4/4] selftests/sched_ext: consume_immed: fix reliability with CPU affinity

[zhidao su]

Two bugs prevented the IMMED slow path from triggering reliably:

1. Dispatch consumed at most one task per ops.dispatch() call.  The IMMED
   slow path requires dsq->nr > 1 in the local DSQ after a
   scx_bpf_dsq_move_to_local() call.  With only one call per dispatch,
   the local DSQ never accumulated two tasks.

   Fix: loop up to 8 times in dispatch, draining USER_DSQ into the local
   DSQ.  On the second iteration the local DSQ already has one task;
   inserting a second raises dsq->nr to 2, triggering schedule_reenq_local
   and calling ops.enqueue() with SCX_TASK_REENQ_IMMED.

2. Workers were not pinned to CPU 0, so the scheduler spread them across
   all CPUs.  USER_DSQ typically had only 0-1 tasks when CPU 0 dispatched,
   so the loop's second iteration rarely found a second task.

   Fix: pin all NUM_WORKERS threads to CPU 0 via
   pthread_attr_setaffinity_np().  With all workers competing for CPU 0,
   USER_DSQ always has a backlog, and every dispatch loop reliably
   accumulates 2+ tasks.

Also move nr_consume_immed_reenq read to after bpf_link__destroy() so
the kernel has fully flushed all counter updates before we check the
assertion.

Fixes: c50dcf533149 ("selftests/sched_ext: Add tests for SCX_ENQ_IMMED and scx_bpf_dsq_reenq()")
Signed-off-by: zhidao su <suzhidao@xiaomi.com>
---
 .../selftests/sched_ext/consume_immed.bpf.c   | 19 +++++++++++++++----
 .../selftests/sched_ext/consume_immed.c       | 15 ++++++++++++---
 2 files changed, 27 insertions(+), 7 deletions(-)

diff --git a/tools/testing/selftests/sched_ext/consume_immed.bpf.c b/tools/testing/selftests/sched_ext/consume_immed.bpf.c
index 9c7808f5abe1..a2a4ee2ee95b 100644
--- a/tools/testing/selftests/sched_ext/consume_immed.bpf.c
+++ b/tools/testing/selftests/sched_ext/consume_immed.bpf.c
@@ -55,10 +55,21 @@ void BPF_STRUCT_OPS(consume_immed_enqueue, struct task_struct *p,
 
 void BPF_STRUCT_OPS(consume_immed_dispatch, s32 cpu, struct task_struct *prev)
 {
-	if (cpu == 0)
-		scx_bpf_dsq_move_to_local(USER_DSQ, SCX_ENQ_IMMED);
-	else
-		scx_bpf_dsq_move_to_local(SCX_DSQ_GLOBAL, 0);
+	int i;
+
+	if (cpu != 0)
+		return;
+
+	/*
+	 * Drain USER_DSQ into the local DSQ with SCX_ENQ_IMMED. Once two or
+	 * more tasks accumulate in the local DSQ, dsq->nr > 1 triggers the
+	 * IMMED slow path (schedule_reenq_local), re-enqueuing IMMED tasks
+	 * through ops.enqueue() with SCX_TASK_REENQ_IMMED.
+	 */
+	for (i = 0; i < 8; i++) {
+		if (!scx_bpf_dsq_move_to_local(USER_DSQ, SCX_ENQ_IMMED))
+			break;
+	}
 }
 
 s32 BPF_STRUCT_OPS_SLEEPABLE(consume_immed_init)
diff --git a/tools/testing/selftests/sched_ext/consume_immed.c b/tools/testing/selftests/sched_ext/consume_immed.c
index 7f9594cfa9cb..41e66cd5e879 100644
--- a/tools/testing/selftests/sched_ext/consume_immed.c
+++ b/tools/testing/selftests/sched_ext/consume_immed.c
@@ -12,6 +12,7 @@
 #include <stdio.h>
 #include <unistd.h>
 #include <pthread.h>
+#include <sched.h>
 #include <bpf/bpf.h>
 #include <scx/common.h>
 #include "consume_immed.bpf.skel.h"
@@ -77,20 +78,28 @@ static enum scx_test_status run(void *ctx)
 
 	stop_workers = false;
 	for (i = 0; i < NUM_WORKERS; i++) {
-		SCX_FAIL_IF(pthread_create(&workers[i], NULL, worker_fn, NULL),
+		pthread_attr_t attr;
+		cpu_set_t cpuset;
+
+		pthread_attr_init(&attr);
+		CPU_ZERO(&cpuset);
+		CPU_SET(0, &cpuset);
+		pthread_attr_setaffinity_np(&attr, sizeof(cpuset), &cpuset);
+		SCX_FAIL_IF(pthread_create(&workers[i], &attr, worker_fn, NULL),
 			    "Failed to create worker %d", i);
+		pthread_attr_destroy(&attr);
 	}
 
 	sleep(TEST_DURATION_SEC);
 
-	reenq = skel->bss->nr_consume_immed_reenq;
-
 	stop_workers = true;
 	for (i = 0; i < NUM_WORKERS; i++)
 		pthread_join(workers[i], NULL);
 
 	bpf_link__destroy(link);
 
+	reenq = skel->bss->nr_consume_immed_reenq;
+
 	SCX_EQ(skel->data->uei.kind, EXIT_KIND(SCX_EXIT_UNREG));
 	SCX_GT(reenq, 0);
 
-- 
2.43.0

Re: [PATCH 1/4] tools/sched_ext: compat.bpf.h: fix scx_bpf_dsq_reenq___compat signature

[Tejun Heo]

On Fri, Mar 27, 2026 at 04:42:35AM +0800, zhidao su wrote:
> scx_bpf_dsq_reenq() is declared with KF_IMPLICIT_ARGS in the kernel BTF,
> which means the BPF verifier automatically injects the
> struct bpf_prog_aux *aux parameter.  The BPF-side weak symbol declaration
> must NOT include the implicit parameter.
> 
> The previous declaration included an explicit aux__prog parameter, which
> caused BPF programs calling scx_bpf_dsq_reenq() through the compat macro
> to fail verification on kernels where the kfunc is available.

Did this actually cause verification failure tho? If BPF isn't ignoring the
implicit arg, it should have just failed ksym_exists test and then fell back
to the older interface or trigger scx_bpf_error().

It's rather obvious that most of your patches are AI slob and I don't see
much value in the selftests that you added either. I'll just revert your
previous patches. Please carefully consider whether what you're sending
actually contributes anything practical and carefully verify the code
changes and description before sending them. These frivolous and plausible
sounding but not actually correct patches are taking bandwidth without
actually improving anything. I'll likely ignore your submissions from now on
unless the trajectory changes substantially.

Thanks.

-- 
tejun