All of lore.kernel.org
 help / color / mirror / Atom feed
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 15/26] sched/deadline: Leave a dying task out of a rebuild of the accounting
Date: Sat, 07 Nov 2026 02:10:27 +0000	[thread overview]
Message-ID: <sashiko-outbox-202482@kernel.org> (raw)
In-Reply-To: <20261107014451.1487825-16-mathieu.desnoyers@efficios.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] sched/deadline: premature bandwidth drop in
  dl_add_task_root_domain()
--

commit 961e96ebfc4954b76eeee2f5e097ac6c0a279fa7
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

sched/deadline: Leave a dying task out of a rebuild of the accounting

This commit skips tasks in TASK_DEAD state that are not on the departed list
when rebuilding root domain deadline bandwidth accounting in
dl_add_task_root_domain().

> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 45a896a4f4615..3f3de4b74a2dc 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -3643,6 +3643,15 @@ void dl_add_task_root_domain(struct task_struct *p)
>  		cpu = p->dl.dl_departed_cpu;
>  		if (!cpu_active(cpu))
>  			goto unlock;
> +	} else if (READ_ONCE(p->__state) == TASK_DEAD) {
> +		/*
> +		 * Dead and not departed: its bandwidth was released at its
> +		 * last schedule, under its runqueue lock and not this one,
> +		 * and dl_bw may still say otherwise. do_task_dead() sets
> +		 * TASK_DEAD under pi_lock before that, so a task found alive
> +		 * here dies after this walk, and releases what it counted.
> +		 */
> +		goto unlock;
>  	}

[Severity: Medium]
Can this drop the bandwidth of a dying task whose 0-lag time is still in the
future?

do_task_dead() calls set_special_state(TASK_DEAD), which sets p->__state =
TASK_DEAD under p->pi_lock and immediately releases p->pi_lock before
calling __schedule().  The task only sets p->dl.dl_departed_cpu later inside
__schedule() -> ... -> dequeue_task_dl() -> task_non_contending() ->
dl_task_depart():

CPU0                                  CPU1
do_task_dead()                        dl_rebuild_rd_accounting()
  set_special_state(TASK_DEAD)          dl_clear_root_domains()
    lock(&p->pi_lock)                     dl_bw_gen++
    p->__state = TASK_DEAD                rd->dl_bw.total_bw = 0
    unlock(&p->pi_lock)                 ...
                                        dl_add_task_root_domain(p)
                                          p->dl.dl_departed_cpu < 0
                                          p->__state == TASK_DEAD
                                          goto unlock  <-- skips p->dl.dl_bw
  __schedule(SM_NONE)
    ...
    task_non_contending(p)
      /* zerolag_time >= 0 */
      dl_task_depart(p, ...)
      start_inactive_timer(p)

Until inactive_timer fires at the 0-lag time, p's bandwidth is missing from
rd->dl_bw.total_bw, allowing sched_dl_overflow() to over-admit new deadline
tasks beyond the root domain's capacity.  In addition, because p joins
dl_departed_list with a stale p->dl.dl_bw_gen, a second rebuild before
inactive_timer fires will take the p->dl.dl_departed_cpu >= 0 branch in
dl_add_task_root_domain() and add p->dl.dl_bw back on top of any newly
admitted tasks.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261107014451.1487825-1-mathieu.desnoyers@efficios.com?part=15

  reply	other threads:[~2026-11-07  2:10 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
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 [this message]
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-202482@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.