From: sashiko-bot@kernel.org
To: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
Cc: linux-rt-devel@lists.linux.dev, tj@kernel.org,
hannes@cmpxchg.org, mkoutny@suse.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 23/29] sched/deadline: Move a task's bandwidth when it must leave its CPU
Date: Sun, 08 Nov 2026 19:41:57 +0000 [thread overview]
Message-ID: <sashiko-outbox-203989@kernel.org> (raw)
In-Reply-To: <20261108185406.1549770-24-mathieu.desnoyers@efficios.com>
Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] sched/deadline: stale dl_bw_cpu on same-rd return in
dl_task_move_bw()
- [Medium] sched/deadline: missed bw move in migrate_task_rq_dl() on
task wakeup
--
commit 83356714a4dd1213bf9ceba0a7dd4eb657180f4e
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
sched/deadline: Move a task's bandwidth when it must leave its CPU
This commit moves a deadline task's bandwidth to the destination CPU's root
domain in migrate_task_rq_dl() when the task leaves an inactive or
disallowed CPU.
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index bc31045e4686f..a35609a10ec5a 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -2873,11 +2873,54 @@ select_task_rq_dl(struct task_struct *p, int cpu, int flags)
> return cpu;
> }
>
> -static void migrate_task_rq_dl(struct task_struct *p, int new_cpu __maybe_unused)
> +/*
> + * Move the bandwidth of @p to the root domain of @new_cpu. Count it there
> + * also if a rebuild left @p out. Add it even without room, since @p runs
> + * there. The caller holds the rq lock of @p, or its pi_lock for a wakeup.
> + */
> +static void dl_task_move_bw(struct task_struct *p, int new_cpu)
> +{
> + struct dl_bw *dl_b;
> + int cpu;
> +
> + if (dl_entity_is_special(&p->dl) || !p->dl.dl_bw)
> + return;
> +
> + guard(raw_spinlock)(&dl_departed_lock);
> + cpu = p->dl.dl_bw_cpu;
> + if (cpu < 0)
> + return;
> + if (p->dl.dl_bw_gen == dl_bw_gen) {
> + if (cpu_rq(cpu)->rd == cpu_rq(new_cpu)->rd)
> + return;
[Severity: Medium]
Does returning here without setting p->dl.dl_bw_cpu = new_cpu leave a stale
offline or disallowed CPU recorded when the task moves within the same root
domain?
During sched_cpu_deactivate(cpu), set_cpu_active(cpu, false) and
balance_push_set(cpu, true) run before cpuset_cpu_inactive(cpu) detaches
cpu from its root domain and rebuilds bandwidth accounting. When
balance_push() or try_to_wake_up() moves a task from the deactivating cpu
to an active new_cpu in the same root domain during that window,
cpu_rq(cpu)->rd == cpu_rq(new_cpu)->rd still holds, so p->dl.dl_bw_cpu is
left pointing to the inactive cpu. If the task then departs on new_cpu
before its 0-lag time, dl_clear_root_domains() and dl_add_task_root_domain()
see !cpu_active(p->dl.dl_bw_cpu) and drop the task's departing bandwidth
from new_cpu's root domain, or dl_task_release_bw() subtracts it from
def_root_domain once detach_destroy_domains() has run.
Updating p->dl.dl_bw_cpu = new_cpu before returning when the root domains
match would keep the recorded CPU valid.
> + dl_b = dl_bw_of(cpu);
> + raw_spin_lock(&dl_b->lock);
> + __dl_sub(dl_b, p->dl.dl_bw, dl_bw_cpus(cpu));
> + raw_spin_unlock(&dl_b->lock);
> + }
> + dl_b = dl_bw_of(new_cpu);
> + raw_spin_lock(&dl_b->lock);
> + __dl_add(dl_b, p->dl.dl_bw, dl_bw_cpus(new_cpu));
> + raw_spin_unlock(&dl_b->lock);
> + p->dl.dl_bw_cpu = new_cpu;
> + p->dl.dl_bw_gen = dl_bw_gen;
> +}
> +
> +static void migrate_task_rq_dl(struct task_struct *p, int new_cpu)
> {
> + int cpu = task_cpu(p);
> struct rq_flags rf;
> struct rq *rq;
>
> + /*
> + * The task must leave a CPU that is no longer active, or that its
> + * mask no longer holds. The new CPU can then be in another root
> + * domain. Move the bandwidth there, as dl_task_offline_migration()
> + * does for a throttled task.
> + */
> + if (unlikely(!cpu_active(cpu) || !cpumask_test_cpu(cpu, p->cpus_ptr)))
> + dl_task_move_bw(p, new_cpu);
[Severity: Medium]
Can this check miss the bandwidth move on wakeup when task_cpu(p) is an
active CPU that is in p->cpus_ptr by the time set_task_cpu() runs?
If a task sleeps on an active housekeeping CPU c0 (task_cpu(p) == c0) and
has its affinity and bandwidth moved to an isolated CPU c1 while asleep,
taking c1 offline leaves the task out of the rebuild (or counted in
def_root_domain). When the task wakes up in try_to_wake_up():
kernel/sched/core.c:select_fallback_rq() {
...
case cpuset:
if (cpuset_cpus_allowed_fallback(p)) {
state = possible;
break;
}
fallthrough;
case possible:
set_cpus_allowed_force(p, task_cpu_fallback_mask(p));
...
}
select_fallback_rq() widens p->cpus_ptr to include c0 before returning to
try_to_wake_up(). If it picks another housekeeping CPU c2, set_task_cpu()
calls migrate_task_rq_dl(p, c2) with cpu = c0, which is both active and now
in p->cpus_ptr, so dl_task_move_bw() is skipped. If select_fallback_rq()
picks c0 itself, try_to_wake_up() sees task_cpu(p) == cpu and skips
set_task_cpu() and migrate_task_rq_dl() altogether. The same happens when
sched_setaffinity() (with admission control disabled) moves a sleeping task
away from c0 across a rebuild and then back to a mask containing c0 before
wakeup. In each case the waking task runs in a root domain that does not
count its bandwidth.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261108185406.1549770-1-mathieu.desnoyers@efficios.com?part=23
next prev parent reply other threads:[~2026-11-08 19:41 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-08 18:53 [PATCH v5 00/29] sched/deadline: bandwidth accounting fixes and selftests Mathieu Desnoyers
2026-11-08 18:53 ` [PATCH v5 01/29] sched: Fix cpuset_mutex double unlock in __sched_setscheduler() Mathieu Desnoyers
2026-11-08 18:53 ` [PATCH v5 02/29] sched: Refuse SCHED_FLAG_KEEP_PARAMS that would change the policy or the class Mathieu Desnoyers
2026-11-08 18:53 ` [PATCH v5 03/29] sched/deadline: Do not admit bandwidth for parameters that are kept Mathieu Desnoyers
2026-11-09 12:42 ` Juri Lelli
2026-11-09 13:16 ` Mathieu Desnoyers
2026-11-08 18:53 ` [PATCH v5 04/29] sched: Let a task boosted by a deadline waiter change its policy Mathieu Desnoyers
2026-11-09 13:38 ` Juri Lelli
2026-11-08 18:53 ` [PATCH v5 05/29] sched/deadline: Do not divide by zero active CPUs of a root domain Mathieu Desnoyers
2026-11-09 14:30 ` Juri Lelli
2026-11-09 14:57 ` Mathieu Desnoyers
2026-11-09 15:09 ` Juri Lelli
2026-11-09 15:22 ` Mathieu Desnoyers
2026-11-08 18:53 ` [PATCH v5 06/29] sched: Take cpuset_mutex for a deadline policy change only with pi Mathieu Desnoyers
2026-11-09 15:06 ` Juri Lelli
2026-11-09 15:22 ` Mathieu Desnoyers
2026-11-08 18:53 ` [PATCH v5 07/29] sched/deadline: Do not lose a throttled task switched out and back Mathieu Desnoyers
2026-11-09 16:05 ` Juri Lelli
2026-11-09 16:29 ` Mathieu Desnoyers
2026-11-09 18:55 ` Mathieu Desnoyers
2026-11-09 18:56 ` Mathieu Desnoyers
2026-11-08 18:53 ` [PATCH v5 08/29] sched/deadline: Take a deadline boost from the waiter's rt_mutex node Mathieu Desnoyers
2026-11-10 11:14 ` Juri Lelli
2026-11-10 13:48 ` Mathieu Desnoyers
2026-11-08 18:53 ` [PATCH v5 09/29] sched/deadline: Reset the deadline and the runtime with the parameters Mathieu Desnoyers
2026-11-10 13:18 ` Juri Lelli
2026-11-10 13:41 ` Mathieu Desnoyers
2026-11-08 18:53 ` [PATCH v5 10/29] sched/deadline: Reset the donor's runtime at a deboost in the class Mathieu Desnoyers
2026-11-08 19:17 ` sashiko-bot
2026-11-09 2:56 ` Mathieu Desnoyers
2026-11-08 18:53 ` [PATCH v5 11/29] sched/deadline: Release the bandwidth of a task that leaves the class asleep Mathieu Desnoyers
2026-11-10 19:47 ` Juri Lelli
2026-11-10 20:26 ` Mathieu Desnoyers
2026-11-08 18:53 ` [PATCH v5 12/29] sched/deadline: Reject SCHED_DEADLINE on exited tasks Mathieu Desnoyers
2026-11-11 6:55 ` Juri Lelli
2026-11-08 18:53 ` [PATCH v5 13/29] sched/deadline: Keep departing bandwidth across a root domain rebuild Mathieu Desnoyers
2026-11-11 12:59 ` Juri Lelli
2026-11-11 15:35 ` Mathieu Desnoyers
2026-11-11 16:19 ` Peter Zijlstra
2026-11-11 19:19 ` Mathieu Desnoyers
2026-11-08 18:53 ` [PATCH v5 14/29] sched/deadline: Fix this_bw when a task is changed during a remote wakeup Mathieu Desnoyers
2026-11-11 13:49 ` Juri Lelli
2026-11-08 18:53 ` [PATCH v5 15/29] sched/deadline: Rebuild the root domains' accounting from the task list Mathieu Desnoyers
2026-11-11 14:24 ` Juri Lelli
2026-11-08 18:53 ` [PATCH v5 16/29] sched/deadline: Record the root domain holding a task's bandwidth Mathieu Desnoyers
2026-11-11 15:54 ` Juri Lelli
2026-11-08 18:53 ` [PATCH v5 17/29] sched/deadline: Leave a dying task out of a rebuild of the accounting Mathieu Desnoyers
2026-11-12 6:40 ` Juri Lelli
2026-11-08 18:53 ` [PATCH v5 18/29] sched/deadline: Move a task's bandwidth only where room was made Mathieu Desnoyers
2026-11-08 19:30 ` sashiko-bot
2026-11-09 2:57 ` Mathieu Desnoyers
2026-11-12 7:03 ` Juri Lelli
2026-11-08 18:53 ` [PATCH v5 19/29] cgroup/cpuset: Wait for an attach before rebuilding the sched domains Mathieu Desnoyers
2026-11-12 7:50 ` Juri Lelli
2026-11-08 18:53 ` [PATCH v5 20/29] cgroup/cpuset: Give back the bandwidth an attach did not move Mathieu Desnoyers
2026-11-12 9:19 ` Juri Lelli
2026-11-08 18:53 ` [PATCH v5 21/29] cgroup/cpuset: Reserve the bandwidth in the root domain a task moves to Mathieu Desnoyers
2026-11-08 19:32 ` sashiko-bot
2026-11-09 2:57 ` Mathieu Desnoyers
2026-11-08 18:53 ` [PATCH v5 22/29] sched/deadline: Make a rebuild use the CPU recorded with a task's bandwidth Mathieu Desnoyers
2026-11-08 19:25 ` sashiko-bot
2026-11-09 2:58 ` Mathieu Desnoyers
2026-11-08 18:54 ` [PATCH v5 23/29] sched/deadline: Move a task's bandwidth when it must leave its CPU Mathieu Desnoyers
2026-11-08 19:41 ` sashiko-bot [this message]
2026-11-09 2:58 ` Mathieu Desnoyers
2026-11-08 18:54 ` [PATCH v5 24/29] sched/deadline: Cancel the replenishment timer with the parameters Mathieu Desnoyers
2026-11-12 9:37 ` Juri Lelli
2026-11-08 18:54 ` [PATCH v5 25/29] sched/deadline: Count the bandwidth a boosted task is given Mathieu Desnoyers
2026-11-12 10:29 ` Juri Lelli
2026-11-08 18:54 ` [PATCH v5 26/29] sched/debug: Show the deadline bandwidth of each runqueue Mathieu Desnoyers
2026-11-12 10:36 ` Juri Lelli
2026-11-08 18:54 ` [PATCH v5 27/29] selftests/sched: Add a test of SCHED_DEADLINE policy round trips Mathieu Desnoyers
2026-11-08 18:54 ` [PATCH v5 28/29] selftests/sched: Test SCHED_DEADLINE bandwidth across a root domain rebuild Mathieu Desnoyers
2026-11-08 18:54 ` [PATCH v5 29/29] selftests/sched: Add a test of SCHED_DEADLINE bandwidth accounting Mathieu Desnoyers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-203989@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=mathieu.desnoyers@efficios.com \
--cc=mkoutny@suse.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.