Re: [PATCH 02/14] sched: Make NOHZ CFS bandwidth checks follow proxy donor

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

Pre-existing issues:
- [High] The newly added donor bandwidth check in `sched_can_stop_tick()` i=
s bypassed by early returns when a FAIR donor delegates execution to a thro=
ttled RT task.
--

--- Patch [2]: [PATCH 02/14] sched: Make NOHZ CFS bandwidth checks follow p=
roxy donor ---
commit 18e332090abc5adb7229eaf795a740846b882ae9
Author: Andrea Righi <[email protected]>

sched: Make NOHZ CFS bandwidth checks follow proxy donor

This commit modifies sched_can_stop_tick() and sched_fair_update_stop_tick()
to check the CFS bandwidth constraints of the selected donor scheduling con=
text
rather than the physical execution context. This prevents constrained FAIR
donors from evading bandwidth enforcement during proxy execution.

Link: https://lore.kernel.org/r/[email protected]

> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index f38332274f8fe..ef0563970d412 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c

[ ... ]

> @@ -1462,14 +1459,17 @@ bool sched_can_stop_tick(struct rq *rq)
>  		return false;
> =20
>  	/*
> -	 * If there is one task and it has CFS runtime bandwidth constraints
> -	 * and it's on the cpu now we don't want to stop the tick.
> +	 * If the selected scheduling context has CFS runtime bandwidth
> +	 * constraints, don't stop the tick. With proxy execution, rq->donor is
> +	 * the selected scheduling context while rq->curr is the task physically
> +	 * executing on its behalf.
> +	 *
>  	 * This check prevents clearing the bit if a newly enqueued task here is
> -	 * dequeued by migrating while the constrained task continues to run.
> +	 * dequeued by migrating while the constrained donor continues to run.
>  	 * E.g. going from 2->1 without going through pick_next_task().
>  	 */
> -	if (__need_bw_check(rq, rq->curr)) {
> -		if (cfs_task_bw_constrained(rq->curr))
> +	if (__need_bw_check(rq->donor)) {
> +		if (cfs_task_bw_constrained(rq->donor))
>  			return false;
>  	}

[Severity: High]
This is a pre-existing issue, but does this placement still allow a CFS
bandwidth-constrained FAIR task to evade its quota if it donates its context
to a throttled RT task?

If a FAIR task with CFS bandwidth constraints blocks on a mutex held by an
RT task, and the RT task exceeds its global RT runtime (becoming throttled),
the RT task's own context becomes ineligible. Proxy execution would then
select the FAIR donor's scheduling context (rq->donor), while the RT task
serves as the execution context (rq->curr).

During global RT throttling, dequeue_top_rt_rq() unsets rt_queued but does
not decrement rt_nr_running, leaving rq->rt.rt_nr_running > 0.

Because sched_can_stop_tick() has early checks for RT tasks (which can
return true when fifo_nr_running > 0), wouldn't the function return early
and completely bypass this newly added __need_bw_check(rq->donor) logic at
the bottom of the function?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260725160513.5747=
[email protected]?part=3D2