Re: [RFC] sched/eevdf: fall back to the leftmost entity when nobody is eligible

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Nov 03, 2026 at 12:42:42PM +0000, Aleksei Fedorov wrote:
> pick_eevdf() returns NULL when more than one entity is runnable and
> entity_eligible() is false for every one of them, including curr. The
> caller then dereferences that pointer.
> 
> On Ubuntu linux-aws 6.8.0-1066.69 and 6.8.0-1063.66 the fault is
> pick_next_task_fair+0x91, mov r14,[rax+0xa0], RAX = 0, CR2 = 0xa0.
> Five oopses on one Xen HVM guest, from 2026-10-24 through 2026-10-28.
> commit 1560d1f6eb6b ("sched/eevdf: Prevent vlag from going out
> of bounds in reweight_eevdf()") is present in both kernels and does
> not stop the NULL return.
> 
> Take the leftmost entity so schedule() can finish. WARN_ON_ONCE records
> the substitution. It does not repair the eligibility state that rejected
> every entity.
> 
> On a guest booted with this change the warning fired once, on
> 2026-10-31 16:08:42 UTC, at pick_eevdf+0x22d in kernel/sched/fair.c:967.
> The guest was still running on 2026-11-03, with no further oops.
> 
> Signed-off-by: Aleksei Fedorov <ring.zero.sh@gmail.com>
> ---
>  kernel/sched/fair.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 0feec172f..1b940ced9 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1196,6 +1196,18 @@ static struct sched_entity *pick_eevdf(struct cfs_rq *cfs_rq, bool protect)
>  	if (!best || (curr && entity_before(curr, best)))
>  		best = curr;
>  
> +	/*
> +	 * More than one entity is runnable, but none was eligible and curr
> +	 * was cleared. Returning NULL makes the caller dereference the
> +	 * result. Take the leftmost entity so schedule() can finish.
> +	 * WARN_ON_ONCE records that substitution. It does not repair the
> +	 * eligibility state that rejected every entity.
> +	 */
> +	if (unlikely(!best)) {
> +		best = __pick_first_entity(cfs_rq);
> +		WARN_ON_ONCE(best);
> +	}
> +
>  	return best;
>  }

That WARN will likely kill you as hard as a NULL deref.

Also, as I've said a million times before; getting into this situation
is bad -- something is messed up, find the root cause, fix that.

First step though, try something recent, there have been a *LOT* of
changes since 6.8