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

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

[Aleksei Fedorov]

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;
 }
 

base-commit: b99b7f60c5b473d374c68b53753153b4aa9e0702
-- 
2.34.1

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

[Peter Zijlstra]

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