[PATCHSET sched_ext/for-7.3-fixes] sched_ext: Fix scx balance callbacks queued across a core-sched pick

[Andrea Righi <arighi@nvidia.com>]

Commit ff0545e0c263 ("sched_ext: Don't leave balance callbacks queued across a
pick retry") queues the scx balance callbacks only when the pick is final.
However, under core scheduling, a pick that returns a task isn't final:
pick_next_task() goes on to pick the SMT siblings, and their dispatch can
release the shared rq lock with the callbacks still queued. Any CPU acquiring
the rq lock in that window triggers the warning in rq_pin_lock().

This was pointed out by Tejun and sashiko in the review of ff0545e0c263 [1][2]
and these are the follow-up fixes.

Patch 1/2 always defers the pending work to irq_work under core scheduling, for
both the local and the sibling picks, and leaves SCX_RQ_BAL_CB_PENDING to the
dispatch in flight that set it.

Patch 2/2 handles the kick_sync wait, which can't be moved to irq_work, by
taking it off the local rq around each dispatch of a core-wide selection and
queueing it again if the rq lock isn't released.

Testing:

 - The core scheduling case (1/2) was reproduced in a 16-CPU VM with SMT (8
   cores, 2 threads each), running scx_qmap -I with two stress-ng sleeper groups
   tagged with different cookies (coresched new -- ...), one of them SCHED_FIFO,
   plus an untagged CPU-bound workload. The warning itself is racy, so a debug
   check in scx_rq_lock_drop() (not part of this series) also reported any scx
   balance callback still queued on the core when the rq lock is released. With
   only ff0545e0c263 applied, the check fired in 5 of 10 runs (always
   deferred_bal_cb, both for sibling and local re-picks) and the warning showed
   up as well; with 1/2 applied, 0 of 16 runs.

 - The kick_sync case (2/2) was reproduced with the same setup and a temporary
   change to scx_qmap that kicks a CPU on another core with SCX_KICK_WAIT on
   every user task enqueue. With 1/2 only, the debug check reported the
   kick_sync callback queued across an rq lock drop, both by a sibling's
   dispatch and by a local re-pick, in 5 of 6 runs, and the rq_pin_lock()
   warning showed up in 2 of them; with 2/2 applied, 0 of 4 runs.

[1] https://lore.kernel.org/r/20261010095208.276806-1-arighi@nvidia.com
[2] https://lore.kernel.org/r/20261017152226.3690249-1-arighi@nvidia.com

Andrea Righi (2):
  sched_ext: Don't queue balance callbacks from a core-sched pick
  sched_ext: Don't leave the kick_sync wait queued across a core-sched pick

 kernel/sched/ext/ext.c | 78 +++++++++++++++++++++++++++++++++++-------
 1 file changed, 66 insertions(+), 12 deletions(-)