[PATCHSET sched_ext/for-7.3-fixes] sched_ext: Fix missing ops.dequeue() on remote local DSQ moves

[Kuba Piecuch <jpiecuch@google.com>]

Hi,

Since ebf1ccff79c4 ("sched_ext: Fix ops.dequeue() semantics"), every task
entering the BPF scheduler's custody gets exactly one ops.dequeue() when
it leaves it. A dispatch to a terminal DSQ ends custody with a flag-less
ops.dequeue() at insertion time.

That doesn't happen when the task is moved to the local DSQ of a CPU other
than the one whose rq it's on (SCX_DSQ_LOCAL_ON dispatch,
scx_bpf_dsq_move_to_local(), scx_bpf_dsq_move*()).
move_remote_task_to_local_dsq() sets p->scx.sticky_cpu to mark the
internal migration, but enqueue_task_scx() only clears it after the task
has been inserted into the destination local DSQ. task_leave_custody()
thus skips the custody exit on insertion, and the task sits on the local
DSQ with SCX_TASK_IN_CUSTODY still set. The BPF scheduler is only told
later, either:

 - when the task is picked, via ops.dequeue(SCX_DEQ_CORE_SCHED_EXEC) from
   set_next_task_scx(), even though core scheduling isn't involved, or

 - on a property change while the task waits on the local DSQ, via
   ops.dequeue(SCX_DEQ_SCHED_CHANGE) for a task already out of custody.

The existing dequeue selftest doesn't notice because it treats the late
SCX_DEQ_CORE_SCHED_EXEC dequeue like a regular dispatch dequeue, and it
still arrives before ops.running().

Patch 1 adds a dequeue_remote selftest that makes remote moves the common
case and fails on a SCX_DEQ_CORE_SCHED_EXEC dequeue, on a task running
without a preceding ops.dequeue(), or on unbalanced ops.enqueue() /
ops.dequeue() calls. Since core scheduling can legitimately pick tasks
straight out of custody, the test is skipped if any task has a core
scheduling cookie when it starts. It isn't added to auto-test-targets
since it fails on the current tree. Patch 2 fixes the bug by clearing
p->scx.sticky_cpu before scx_do_enqueue_task(). Patch 3 enables the test.

This is based on sched_ext/for-7.3-fixes (94480606a677) and also applies
cleanly to sched_ext/for-next. Testing was done on x86_64 in virtme-ng
with 4 vCPUs in an SMT topology (2 cores x 2 threads) and
CONFIG_SCHED_CORE=y, with no core scheduling cookies in use.

Without patch 2, dequeue_remote fails in every run (30/30), within the
first few custody enqueues after the scheduler is loaded:

  sched_ext: dequeue_remote: dequeue_remote.bpf.c:143: 156 (runner): late ops.dequeue() with SCX_DEQ_CORE_SCHED_EXEC (enq_cpu=1 cpu=3 seq=1)
     ...
     ops_dequeue+0x114/0x170
     set_next_task_scx+0x104/0x1e0

and the full sched_ext selftest suite reports:

  PASSED:  31
  SKIPPED: 1  (nohz_tick)
  FAILED:  1  (dequeue_remote)

With patch 2, dequeue_remote passes in every run (30/30). A typical run
does ~140k custody enqueues across both variants, each matched by exactly
one ops.dequeue(), with ~90k of them followed by the task running on a
CPU other than the one it was enqueued on. The full suite reports:

  PASSED:  32
  SKIPPED: 1  (nohz_tick)
  FAILED:  0

With a core scheduling cookie in use, dequeue_remote is skipped as
expected.

Thanks,
Kuba

Assisted-by: Claude:claude-opus-5.5

Kuba Piecuch (3):
  selftests/sched_ext: Add a test for ops.dequeue() on remote local DSQ
    moves
  sched_ext: Call ops.dequeue() when a task arrives on a remote local
    DSQ
  selftests/sched_ext: Enable the dequeue_remote test

 kernel/sched/ext/ext.c                        |  16 +-
 tools/testing/selftests/sched_ext/Makefile    |   1 +
 .../selftests/sched_ext/dequeue_remote.bpf.c  | 272 ++++++++++++++++++
 .../selftests/sched_ext/dequeue_remote.c      | 243 ++++++++++++++++
 4 files changed, 527 insertions(+), 5 deletions(-)
 create mode 100644 tools/testing/selftests/sched_ext/dequeue_remote.bpf.c
 create mode 100644 tools/testing/selftests/sched_ext/dequeue_remote.c


base-commit: 94480606a677deb68d5622cf0ded88626514b3f2
-- 
2.56.0.rc1.315.gc6ed9934b7-goog