sched_ext: Fix bypassed tasks stranded by the reenqueue limit

scx_do_enqueue_task() counts a task's reenqueues until the task runs. Past
SCX_REENQ_MAX_REPEAT it ejects the owning scheduler and leaves the task off
every DSQ for the scheduler's exit to requeue. The count comes before the
bypass test, so it also counts the reenqueues of a task whose scheduler is
bypassing.

Those reenqueues are not the scheduler's placements, and ejecting the
scheduler for them fixes nothing. Under bypass the kernel queues the
scheduler's tasks on the bypass DSQs. A host calling
scx_bpf_reenqueue_local() reenqueues a bypassed child's tasks on the cpu's
local DSQ along with its own, and the reject drain reenqueues a consumed
task that a cap check rejected.

In the following patches, the consume itself reenqueues a task it can't run
right away, and the bypass load balancer reenqueues a task at its home.

The count is reset only when the task runs or leaves sched_ext, so an
ejection can lead to a stranding the exit does not recover:

 1. the task's reenqueues pass the limit, which ejects its scheduler and
    strands the task
 2. the exit's scx_bypass() cycles the task through dequeue and enqueue,
    which requeues it on a bypass DSQ with the count still past the limit
 3. the task's next reenqueue under bypass strands it again
 4. scx_bypass() requeues stranded tasks only when the scheduler wasn't
    bypassing yet, so the task stays off every DSQ until the disable walks
    the tasks
 5. the disable takes scx_enable_mutex, the cgroup lock and scx_fork_rwsem
    before the walk, and a sub-scheduler's disable the cpu hotplug lock too.
    It hangs if the stranded task holds one of them, forking, attaching to a
    cgroup or doing a cpu hotplug

Test bypass before the count. A task reenqueued under bypass stays queued
until a later dispatch or balancer pass, so there is no tight loop to bound,
and the task's first run resets the count. The offline test moves up with it
to stay ahead of the bypass test. A reenqueue on an offline cpu goes to the
local DSQ and isn't counted either.

A host that keeps calling scx_bpf_reenqueue_local() could get a bypassed
child ejected, as the child's tasks on the local DSQ counted against the
child. The reenqueues are the host's, and its own tasks still count against
it.

v2: The description lists the cpu hotplug lock among the locks a
sub-scheduler's disable takes before the walk.

Fixes: 7706d6e4f2e3 ("sched_ext: Bound per-task reenqueues and eject the owning scheduler")
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