sched_ext: Fix the stall watchdog testing and blaming the wrong sched under bypass

While a sched is bypassing, its tasks are run by its host, the nearest
ancestor that isn't bypassing. check_rq_for_timeouts() tests a runnable task
against its owner's timeout. Since 2c91169377f4 ("sched_ext: Blame the DSQ's
owning scheduler for a runnable stall"), it ejects the sched owning the DSQ
the task waits on. The sched tested, the sched ejected and the sched running
the task can all differ.

- Timeouts are per sched. A bypassing sub-scheduler with a 2s timeout under
  a root with the default 30s has its tasks on the root's bypass DSQ. The
  root, not bypassing itself, consumes that DSQ before calling
  ops.dispatch() only on every other pass, and on the others only after
  ops.dispatch() yields nothing. A task that waits 2s there ejects the root,
  disabling all of sched_ext.

- A bypassing owner's task on the local DSQ is blamed on the owner, which
  places nothing while bypassing. If the owner is already exiting, e.g.
  during its own disable, the exit is a no-op and nothing is ejected. If the
  host isn't running the task, the owner's disable, which waits on it, may
  never finish.

- The wait isn't restarted when bypass moves a task. The time it waited
  under its owner counts against the host once it is on the host's bypass
  DSQ, and its time there against the owner once bypass lifts.

The sched running a task is its owner, or the host while the owner is
bypassing. Test the task against that sched's timeout and blame it. A bypass
requeue can change the sched running a task, so restart the wait of every
task scx_bypass() requeues except the root's own, which the root runs
bypassing or not. Single-scheduler behavior is unchanged.

A task that migrates while scx_bypass() works through the cpus, leaving one
before its requeue and arriving on another after it, is requeued by neither
and keeps its wait, which then counts against the sched now running it. That
is what happened to every task before this patch. This might be worth
addressing in the future, but the race is rare and the real-world
implications should be limited.

Fixes: 2c91169377f4 ("sched_ext: Blame the DSQ's owning scheduler for a runnable stall")
Cc: stable@vger.kernel.org # v7.3+: 30fb2b1e4d41: sched_ext: Fix the running task keeping its protection into bypass
Cc: stable@vger.kernel.org # v7.3+: 5809f749fbdb: sched_ext: Fix a bypassed task stalling on a cpu its scheduler has no caps on
Cc: stable@vger.kernel.org # v7.3+
Reported-by: Andrea Righi <arighi@nvidia.com>
Link: https://lore.kernel.org/all/at4l0yXTk7T_ouk0@gpd4/
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Andrea Righi <arighi@nvidia.com>

0 files changed, 0 insertions, 0 deletions