Re: [PATCH 01/15] sched: Make NOHZ CFS bandwidth checks follow proxy donor

[email protected]
Newsgroups dev.linux.lists.sched-ext
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] NOHZ_FULL isolation is broken for RT tasks that preempt a constrained FAIR task because the tick dependency is erroneously kept active.
--

--- Patch [1]: [PATCH 01/15] sched: Make NOHZ CFS bandwidth checks follow proxy donor ---
commit 4ed25113b5b2751dc0d63ef337fd5d561e7a7554
Author: Andrea Righi <[email protected]>

sched: Make NOHZ CFS bandwidth checks follow proxy donor

This commit updates the NOHZ CFS bandwidth checks to evaluate the proxy
donor rather than the physical execution context. This ensures that a
retained proxy donor correctly enforces bandwidth accounting even when
the lock owner is queued in another scheduling class.

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

> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 0697ed0f1c3d2..6e835d2780cfd 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c

[ ... ]

> @@ -1431,6 +1428,14 @@ bool sched_can_stop_tick(struct rq *rq)
>  	if (rq->dl.dl_nr_running)
>  		return false;
>  
> +	/*
> +	 * The selected scheduling context can be a constrained FAIR donor even
> +	 * when rq->curr is an RT task. Check it before the RT fast paths below,
> +	 * which may report that the tick can stop for a throttled RT context.
> +	 */
> +	if (__need_bw_check(rq->donor) && cfs_task_bw_constrained(rq->donor))
> +		return false;
> +

[Severity: High]
Does evaluating rq->donor here during enqueue cause an issue when an RT task
wakes up on a NOHZ_FULL CPU that is currently running a bandwidth-constrained
FAIR task?

During the RT task wakeup, the enqueue path reaches this check before the
context switch:

enqueue_task_rt() -> add_nr_running() -> sched_update_tick_dependency() ->
sched_can_stop_tick()

At this point, rq->donor has not yet been updated and still points to the
currently running FAIR task. This causes the check to return false, which
keeps the TICK_DEP_BIT_SCHED dependency set.

After the context switch to the RT task, rq->donor is updated, but
sched_update_tick_dependency() is not called again on context switch, and
set_next_task_rt() does not actively clear the tick dependency.

Could this cause the incoming RT task to run with the timer tick erroneously
enabled, breaking NOHZ_FULL isolation?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.