Re: [PATCH v3 02/10] sched/fair: Credit a persistent, queue-depth-scaled vlag margin

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] __enqueue_entity() fails to initialize se->max_slice before adding the entity to the augmented RB-tree, poisoning the tree's max_slice.
--

commit c9a9a8b18145d7a6a58148e991409677da519193
Author: Wanpeng Li <wanpengli@tencent.com>

sched/fair: Credit a persistent, queue-depth-scaled vlag margin

This commit replaces the credit-to-zero buddy system with a bounded
positive-vlag margin. The margin scales with runqueue depth to preserve
the buddy's eligibility across multiple scheduling decisions without
exceeding EEVDF fairness bounds.

> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index e7f5ea25fdae3..c6502db62cd3e 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
[ ... ]
> @@ -9371,11 +9395,23 @@ eevdf_credit_entity_vlag(struct cfs_rq *cfs_rq, struct sched_entity *se)
>  	avruntime = avg_vruntime(cfs_rq);
>  	vlag = entity_lag(cfs_rq, se, avruntime);
>  
> -	/* Already eligible: nothing to do. */
> -	if (vlag >= 0)
> -		return;
> +	/* Clamp the margin to entity_lag()'s bound so place_entity() keeps it. */
> +	max_slice = cfs_rq_max_slice(cfs_rq) + TICK_NSEC;

[Severity: High]
This isn't a bug introduced by this patch, but does the tree's max_slice
contain poisoned data here?

When an entity is dequeued, rb_erase_augmented_cached() removes the node
but does not clear se->max_slice. When enqueued again, __enqueue_entity()
initializes se->min_vruntime and se->min_slice, but misses se->max_slice:

kernel/sched/fair.c:__enqueue_entity() {
	sum_w_vruntime_add(cfs_rq, se);
	se->min_vruntime = se->vruntime;
	se->min_slice = se->slice;
	// Missing se->max_slice = se->slice; here?
	rb_add_augmented_cached(&se->run_node, &cfs_rq->tasks_timeline,
				__entity_less, &min_vruntime_cb);
}

Won't the new leaf node propagate a potentially large, stale max_slice from its
previous subtree up to the root? This would artificially inflate
cfs_rq_max_slice() and corrupt the lag_limit calculated here, potentially
allowing tasks to accumulate massive lag while sleeping and breaking EEVDF
fairness bounds.

> +	lag_limit = calc_delta_fair(max_slice, se);
> +	margin = eevdf_persistent_margin(cfs_rq, se);
> +	if (lag_limit && margin > lag_limit)
> +		margin = lag_limit;
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260612013355.59231-1-kernellwp@gmail.com?part=2