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 v4 09/26] sched/deadline: Reset the deadline and the runtime with the parameters
Date: Sat, 07 Nov 2026 02:18:50 +0000 [thread overview]
Message-ID: <sashiko-outbox-202497@kernel.org> (raw)
In-Reply-To: <20261107014451.1487825-10-mathieu.desnoyers@efficios.com>
Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] sched/deadline: unreset donor period in switched_from_dl()
when dl_runtime != 0
- [Medium] sched/deadline: donor deadline and runtime kept on deboost
after setattr
--
commit e10fc72d0029b6302955712a86b151e84624b177
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
sched/deadline: Reset the deadline and the runtime with the parameters
This commit resets dl_se->deadline and dl_se->runtime in
__dl_clear_params() and in switched_from_dl() when a deboosted task has no
dl_runtime of its own.
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index b8b0076870a64..f389620e6fc9a 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -3580,6 +3580,16 @@ static void switched_from_dl(struct rq *rq, struct task_struct *p)
> if (task_on_rq_queued(p) && p->dl.dl_runtime)
> task_non_contending(&p->dl, false);
>
> + /*
> + * Deboosted from priority inheritance with no parameters of its own:
> + * the deadline and the runtime are the donor's. A change into the
> + * class then starts a period from the parameters it is given.
> + */
> + if (!p->dl.dl_runtime) {
> + p->dl.deadline = 0;
> + p->dl.runtime = 0;
> + }
[Severity: Medium]
What happens in switched_from_dl() when a task that still carries pre-0-lag
parameters (p->dl.dl_runtime != 0) is PI-boosted by a SCHED_DEADLINE waiter
and then deboosted?
When the task is boosted before its inactive_timer fires, switched_to_dl()
cancels inactive_timer and replenish_dl_entity() overwrites p->dl.deadline
and p->dl.runtime from the donor's pi_params. On deboost, p->dl.dl_runtime
is non-zero, so switched_from_dl() skips the reset and passes the
donor-modified deadline and runtime to task_non_contending(), mixing them
with the task's old dl_period and dl_runtime.
Depending on the donor's parameters, this either releases the task's old
bandwidth before its real 0-lag time or leaves the donor's future deadline
and runtime in place for a subsequent entry into SCHED_DEADLINE.
[Severity: Medium]
Can a task keep the donor's deadline and runtime if sched_setattr() gives
it SCHED_DEADLINE parameters while it is PI-boosted?
If a non-deadline task is boosted into dl_sched_class and then configured
as SCHED_DEADLINE via sched_setattr() before unlocking the rt_mutex, both
__sched_setscheduler() and the subsequent deboost in rt_mutex_setprio()
keep the task in dl_sched_class without calling switched_from_dl():
kernel/sched/core.c:rt_mutex_setprio() {
...
} else {
p->dl.dl_boosted = 0;
}
...
}
When rt_mutex_setprio() clears dl_boosted, enqueue_dl_entity() only calls
setup_new_dl_entity() if dl_se->deadline is already in the past, so the
task runs unboosted on the donor's remaining runtime and deadline instead
of starting a period from its own parameters.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261107014451.1487825-1-mathieu.desnoyers@efficios.com?part=9
next prev parent reply other threads:[~2026-11-07 2:18 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-07 1:44 [PATCH v4 00/26] sched/deadline: bandwidth accounting fixes and selftests Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 01/26] sched: Fix cpuset_mutex double unlock in __sched_setscheduler() Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 02/26] sched: Refuse SCHED_FLAG_KEEP_PARAMS that would change the policy or the class Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 03/26] sched/deadline: Do not admit bandwidth for parameters that are kept Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 04/26] sched: Let a task boosted by a deadline waiter change its policy Mathieu Desnoyers
2026-11-07 2:13 ` sashiko-bot
2026-11-08 15:03 ` Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 05/26] sched/deadline: Do not divide by zero active CPUs of a root domain Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 06/26] sched: Take cpuset_mutex for a deadline policy change only with pi Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 07/26] sched/deadline: Do not lose a throttled task switched out and back Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 08/26] sched/deadline: Take a deadline boost from the waiter's rt_mutex node Mathieu Desnoyers
2026-11-07 2:25 ` sashiko-bot
2026-11-08 15:04 ` Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 09/26] sched/deadline: Reset the deadline and the runtime with the parameters Mathieu Desnoyers
2026-11-07 2:18 ` sashiko-bot [this message]
2026-11-08 15:05 ` Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 10/26] sched/deadline: Release the bandwidth of a task that leaves the class asleep Mathieu Desnoyers
2026-11-07 2:23 ` sashiko-bot
2026-11-08 15:07 ` Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 11/26] sched/deadline: Reject SCHED_DEADLINE on exited tasks Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 12/26] sched/deadline: Keep departing bandwidth across a root domain rebuild Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 13/26] sched/deadline: Do not take a waking task's bandwidth off a runqueue it left Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 14/26] sched/deadline: Rebuild the root domains' accounting from the task list Mathieu Desnoyers
2026-11-07 2:22 ` sashiko-bot
2026-11-08 15:08 ` Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 15/26] sched/deadline: Leave a dying task out of a rebuild of the accounting Mathieu Desnoyers
2026-11-07 2:10 ` sashiko-bot
2026-11-08 15:09 ` Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 16/26] sched/deadline: Record the root domain holding a task's bandwidth Mathieu Desnoyers
2026-11-07 2:35 ` sashiko-bot
2026-11-08 15:10 ` Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 17/26] sched/deadline: Move a task's bandwidth only where room was made Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 18/26] cgroup/cpuset: Wait for an attach before rebuilding the sched domains Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 19/26] cgroup/cpuset: Give back the bandwidth an attach did not move Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 20/26] sched/deadline: Credit a rebuild to the CPU recorded with the task's bandwidth Mathieu Desnoyers
2026-11-07 2:48 ` sashiko-bot
2026-11-08 15:11 ` Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 21/26] sched/deadline: Cancel the replenishment timer with the parameters Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 22/26] sched/deadline: Count the bandwidth a boosted task is given Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 23/26] sched/debug: Show the deadline bandwidth of each runqueue Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 24/26] selftests/sched: Add a test of SCHED_DEADLINE policy round trips Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 25/26] selftests/sched: Test SCHED_DEADLINE bandwidth across a root domain rebuild Mathieu Desnoyers
2026-11-07 1:44 ` [PATCH v4 26/26] selftests/sched: Add a test of SCHED_DEADLINE bandwidth accounting Mathieu Desnoyers
2026-11-07 2:25 ` sashiko-bot
2026-11-08 15:11 ` 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-202497@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.