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 18/29] sched/deadline: Move a task's bandwidth only where room was made
Date: Sun, 08 Nov 2026 19:30:20 +0000 [thread overview]
Message-ID: <sashiko-outbox-203951@kernel.org> (raw)
In-Reply-To: <20261108185406.1549770-19-mathieu.desnoyers@efficios.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] sched/deadline: skipped bandwidth move in
__set_cpus_allowed_ptr_locked()
--
commit e053f633c12ae5159a18a1d6a2e9e44a383c8ab0
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
sched/deadline: Move a task's bandwidth only where room was made
This commit adds the SCA_DL_BW_RESERVED flag and
set_cpus_allowed_bw_reserved() so that set_cpus_allowed_dl() only moves a
deadline task's bandwidth across root domains when the caller has reserved
space in the destination root domain.
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index bf722f5ff97e5..030106b3d97f4 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3272,6 +3272,22 @@ int set_cpus_allowed_ptr(struct task_struct *p, const struct cpumask *new_mask)
> }
> EXPORT_SYMBOL_GPL(set_cpus_allowed_ptr);
>
> +/*
> + * Like set_cpus_allowed_ptr(), for a caller that has made room for the
> + * deadline bandwidth of @p in the root domain of @new_mask. Move that
> + * bandwidth there with @p. Return 0 on success, or a negative error
> + * code.
> + */
> +int set_cpus_allowed_bw_reserved(struct task_struct *p, const struct cpumask *new_mask)
> +{
> + struct affinity_context ac = {
> + .new_mask = new_mask,
> + .flags = SCA_DL_BW_RESERVED,
> + };
> +
> + return __set_cpus_allowed_ptr(p, &ac);
> +}
[Severity: Medium]
Can __set_cpus_allowed_ptr_locked() skip set_cpus_allowed_dl() when
SCA_DL_BW_RESERVED is set and p->cpus_mask already equals ctx->new_mask?
kernel/sched/core.c:__set_cpus_allowed_ptr_locked() {
...
if (!(ctx->flags & SCA_MIGRATE_ENABLE)) {
if (cpumask_equal(&p->cpus_mask, ctx->new_mask)) {
if (ctx->flags & SCA_USER)
swap(p->user_cpus_ptr, ctx->user_mask);
goto out;
}
...
}
With this patch, an affinity change without SCA_DL_BW_RESERVED (such as
sched_setaffinity() when sched_rt_runtime_us is -1 on a cpuset spanning
two root domains) updates p->cpus_mask to CPUs in root domain B while
leaving p->dl.dl_bw_cpu in root domain A. If the task is then attached to
a cpuset in root domain B whose effective affinity mask matches
p->cpus_mask, cpuset_can_attach() reserves bandwidth in root domain B and
cpuset_attach_task() calls set_cpus_allowed_bw_reserved(), but
__set_cpus_allowed_ptr_locked() takes the cpumask_equal() early exit
without calling do_set_cpus_allowed() -> set_cpus_allowed_dl().
That leaves p->dl.dl_bw counted in source root domain A, keeps
p->dl.dl_bw_cpu pointing to root domain A, and leaks the destination
reservation in root domain B. Later commits in this series ("cgroup/cpuset:
Give back the bandwidth an attach did not move" and "sched/deadline: Move
a task's bandwidth when it must leave its CPU") only partially mitigate
this: if the task was sleeping during the earlier unreserved affinity
change, p->dl.dl_bw_cpu stays in root domain A, the cpumask_equal() early
exit still skips set_cpus_allowed_dl() on attach, and cpuset_free_dl_bw()
refunds root domain B while the sleeping task's bandwidth remains counted
in root domain A.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261108185406.1549770-1-mathieu.desnoyers@efficios.com?part=18
next prev parent reply other threads:[~2026-11-08 19:30 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 [this message]
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
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-203951@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.