Re: [PATCH v3 03/10] sched/fair: Credit queued next-buddy via canonical requeue

[sashiko-bot@kernel.org]

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

New issues:
- [High] Unconditional setting of `se->rel_deadline = 1` ignores `sched_feat(PLACE_REL_DEADLINE)`, leaking relative deadline flags and corrupting absolute deadlines on reweighting.

Pre-existing issues:
- [High] `__enqueue_entity` fails to reset `se->max_slice = se->slice`, causing stale subtree maximums to incorrectly inflate the augmented rbtree.
--

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

sched/fair: Credit queued next-buddy via canonical requeue

This commit extends eevdf_credit_entity_vlag() to handle a queued
entity. It uses the canonical requeue pattern to keep sum_w_vruntime
consistent with entity_key(), preserving the slice and shifting the
deadline.

> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c

[ ... ]

> @@ -9422,7 +9424,22 @@ eevdf_credit_entity_vlag(struct cfs_rq *cfs_rq, struct sched_entity *se)
>  		return;
>  	}
>  
> -	/* Queued entities are left unchanged by this helper path. */
> +	/*
> +	 * Canonical place_entity()-paired requeue: see dequeue_entity() and
> +	 * requeue_delayed_entity(). place_entity() restores the deadline via
> +	 * "se->deadline += se->vruntime", so make the deadline relative to
> +	 * se->vruntime here (not avg_vruntime). This preserves the slice and
> +	 * shifts the deadline by exactly -credit, mirroring the curr branch
> +	 * and keeping deadline > vruntime.
> +	 */
> +	se->vlag = vlag + (s64)credit;
> +	se->deadline -= se->vruntime;
> +	se->rel_deadline = 1;

[Severity: High]
Does setting the relative deadline flag unconditionally here cause an issue
if the PLACE_REL_DEADLINE feature is disabled?

Looking at place_entity(), the flag is only cleared if the feature is enabled:

place_entity() {
	...
	if (sched_feat(PLACE_REL_DEADLINE) && se->rel_deadline) {
		se->deadline += se->vruntime;
		se->rel_deadline = 0;
		return;
	}
	...
	se->deadline = se->vruntime + vslice;
}

If the feature is disabled, place_entity() computes an absolute deadline but
leaves se->rel_deadline set to 1. If the task then sleeps and its nice value
changes, rescale_entity() checks se->rel_deadline and will incorrectly apply
relative scaling to the absolute deadline:

rescale_entity() {
	...
	if (se->rel_deadline)
		se->deadline = div64_long(se->deadline * old_weight, weight);
	...
}

Could this arithmetic overflow and corrupt the deadline, potentially breaking
the rbtree priority ordering?

> +	cfs_rq->nr_queued--;
> +	__dequeue_entity(cfs_rq, se);
> +	place_entity(cfs_rq, se, 0);
> +	__enqueue_entity(cfs_rq, se);

[Severity: High]
This is a pre-existing issue, but does the call to __enqueue_entity()
expose a stale max_slice issue in the augmented rbtree?

When an entity is inserted as a leaf node, __enqueue_entity() resets the
min_vruntime and min_slice, but appears to leave max_slice untouched:

__enqueue_entity() {
	sum_w_vruntime_add(cfs_rq, se);
	se->min_vruntime = se->vruntime;
	se->min_slice = se->slice;
	rb_add_augmented_cached(&se->run_node, &cfs_rq->tasks_timeline,
				__entity_less, &min_vruntime_cb);
}

If the task previously had a large max_slice (for instance, when it was a
parent of tasks with large slices), does that stale max_slice propagate up
the tree during rb_add_augmented_cached()?

Could this artificially inflate cfs_rq_max_slice(cfs_rq) and circumvent the
lag clamping bounds in entity_lag(), allowing tasks to hoard excessive lag?

> +	cfs_rq->nr_queued++;
>  }

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