Re: [PATCH 01/15] sched: Make NOHZ CFS bandwidth checks follow proxy donor
| 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