From nobody Thu Apr 9 17:57:44 2026 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7B5DA3976A4 for ; Tue, 3 Mar 2026 19:41:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772566889; cv=none; b=HaFR7Lzd/Ml1jEDM0yHLI5AYAAr1FYMjtNRaqhzFteAkjxRTvkKJJEHdbZXSsfb2McTSex95W6CttZbtg4ByfYFVI+QNe0097RlCQqpbibCu6xnF7TSOY2f8d9Uy2bhk1zJtw04dZMaV5bL+XZn0xyK+BzQxm0aH2wRilOMXhRk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772566889; c=relaxed/simple; bh=HiS5TtRZsZWXdP3jkFLUYDvRt1ElP8Uzxxx+mM1jjZ0=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=faVUaVAFSb6JjY/yx8s8iUi9N6ANxRiJbdN4og+bre0ziC6NLKVEyGOkdF4xAsNx/74s6qQMCYaiegFe0G5Ua6y6GQIab8zZmWpyUA6/P7gaLlsljQ0IVEjQOpKYCxyVM6clzvflENMUwNiEq8QsDroduyiOJJiW2UUEWAcP1J4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--jstultz.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=d2d5CPQP; arc=none smtp.client-ip=209.85.216.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--jstultz.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="d2d5CPQP" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-354c0234c1fso4852098a91.2 for ; Tue, 03 Mar 2026 11:41:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1772566888; x=1773171688; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=+lOtgMNKR1dua1sAHHjEsZRLuNM3oV2RL3ZyBPVyxjo=; b=d2d5CPQPOkbSI1jCadqH22DC++PGbv6Wa+DdAW2mjXZTHrO6amgjlfbB5Q6cNl5Odh U/UGyKiBLIb+hhhayBdg9tFi7wABTJnJqO0RQiyYsnl9kqHeAHwtVCncPUpig/dUxctT kgKJemVFqb6qRSux+ASERBuEFjGAoJWehcbrTVI8ImMfVmzA7vs5zH/ySPVnHZZWvgqq 8Vtn86d3bVeKd3dtqT5+QwkJNcA6UpO+agqLAMsIvOGQRdhP8auIPoMKblI411CR9vNy DBKtA5AxtJpYWItRwvHu2Rl2lmiYAHJKJNpVvhpPAUG1o5ncTZAfyU66zfpBuWfW3jHE NaYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772566888; x=1773171688; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=+lOtgMNKR1dua1sAHHjEsZRLuNM3oV2RL3ZyBPVyxjo=; b=ONO9YqBb7fQpsUfFWIjOx1g5ozQ4Otdww053fuPpRBAxAUFSdAnEJ4HyTHisYHi47O /MbI4s1j3bqTgpEHm8PPs2ORNuhahJ4eOq5XCtuzq7yRTg1JDmBHEZVj/HJMlhZA7SCM o83CVsmPvpBZ5RguvE4yV7+anqH1xRj5Ot3kdoWQfnIWtbMcJHtw2+7wtljFW2ItXkgP PXyWf9DYFXD4BcoW5V5+P8HNj9sI3gkq2aOaqAgC+2Vegod+AL1WkzXoPMCsEn+Q4cvG SsAOkRcIucZkFq3NWOoxD3NXtGytYJm3Ok0W1esgn9k05LOY48QEw25qOtwXtJHKhxqx 1Kdg== X-Gm-Message-State: AOJu0Ywebn7z0pzmJN+6LjIOF/cR92b+VheYhTflr35AgAJhVSS42A2h SuSQpbUCbAifBhRrw4HgCqOiQfCyM04wShJcIR7Q+x26LLBf8ngGdJZqCaWjJ4GVx0MBW6RomiQ HUbnLZ01JJ1h6w4U1PA9vngGoEf2SXz51dDDi7esynUEEipd/APpifM9ACvvBZS6masFrMAuvzX JXofEaW93nrdhB6yDS64tR+5ZMCaavfSHzV9epjzcZVCO/jViS X-Received: from pjsv10.prod.google.com ([2002:a17:90a:634a:b0:359:803b:2e2b]) (user=jstultz job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:4b8c:b0:356:5b3d:2249 with SMTP id 98e67ed59e1d1-35965ce46famr12838037a91.32.1772566887391; Tue, 03 Mar 2026 11:41:27 -0800 (PST) Date: Tue, 3 Mar 2026 19:41:12 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.53.0.473.g4a7958ca14-goog Message-ID: <20260303194120.4102982-1-jstultz@google.com> Subject: [PATCH] [RFC]: sched/deadline: Avoid double enqueue_pushable_dl_task() warning From: John Stultz To: LKML Cc: John Stultz , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Suleiman Souhlal , K Prateek Nayak , kernel-team@android.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" In testing with the full Proxy Execution patch stack, I found I would occasionally trip over the !RB_EMPTY_NODE() WARN_ON in enqueue_pushable_dl_task(), where the task we're adding to the pushable list is already enqueued. This triggers from put_prev_task_dl(), where it seems we go into put_prev_task_dl() -> update_curr_dl() -> update_curr_dl_se() [hitting the dl_runtime_exceeded() case] -> enqueue_task_dl() -> enqueue_pushable_dl_task() Adding the task to the pushable the first time. Then we back up the call stack to put_prev_task_dl(), which at the end again calls enqueue_pushable_dl_task(), trying to add it a second time, tripping the warning. To avoid this, add a dl_task_pushable() helper which we can use to replace the RB_EMPTY_NODE checks elsewhere, and then before enqueueing in put_prev_task_dl(), we can first check dl_task_pushable() to avoid the double enqueue. I've only really tripped this while stress testing the full Proxy Execution patch series, and I haven't had time to do the same level of stress testing with vanilla, so its possible this isn't likely to occur with the current upstream, but it seems like it could happen, so I wanted to send this out for comment. Fixes: 63ba8422f876e ("sched/deadline: Introduce deadline servers") Signed-off-by: John Stultz --- Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Juri Lelli Cc: Vincent Guittot Cc: Dietmar Eggemann CC: Steven Rostedt Cc: Ben Segall Cc: Mel Gorman Cc: Valentin Schneider Cc: Suleiman Souhlal Cc: K Prateek Nayak Cc: kernel-team@android.com --- kernel/sched/deadline.c | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index d08b004293234..7a97147560eb3 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -571,6 +571,11 @@ static inline int has_pushable_dl_tasks(struct rq *rq) return !RB_EMPTY_ROOT(&rq->dl.pushable_dl_tasks_root.rb_root); } =20 +static inline bool dl_task_pushable(struct task_struct *p) +{ + return !RB_EMPTY_NODE(&p->pushable_dl_tasks); +} + /* * The list of pushable -deadline task is not a plist, like in * sched_rt.c, it is an rb-tree with tasks ordered by deadline. @@ -579,7 +584,7 @@ static void enqueue_pushable_dl_task(struct rq *rq, str= uct task_struct *p) { struct rb_node *leftmost; =20 - WARN_ON_ONCE(!RB_EMPTY_NODE(&p->pushable_dl_tasks)); + WARN_ON_ONCE(dl_task_pushable(p)); =20 leftmost =3D rb_add_cached(&p->pushable_dl_tasks, &rq->dl.pushable_dl_tasks_root, @@ -599,7 +604,7 @@ static void dequeue_pushable_dl_task(struct rq *rq, str= uct task_struct *p) struct rb_root_cached *root =3D &dl_rq->pushable_dl_tasks_root; struct rb_node *leftmost; =20 - if (RB_EMPTY_NODE(&p->pushable_dl_tasks)) + if (!dl_task_pushable(p)) return; =20 leftmost =3D rb_erase_cached(&p->pushable_dl_tasks, root); @@ -2646,6 +2651,21 @@ static void put_prev_task_dl(struct rq *rq, struct t= ask_struct *p, struct task_s if (task_is_blocked(p)) return; =20 + /* + * its possible the following call chain from + * update_curr_dl() called above has already + * added us to the pushable list: + * update_curr_dl() + * -> update_curr_dl_se() + * -> enqueue_task_dl() + * -> enqueue_pushable_dl_task() + * + * So check dl_task_pushable() first to make sure we don't + * get added twice + */ + if (dl_task_pushable(p)) + return; + if (on_dl_rq(&p->dl) && p->nr_cpus_allowed > 1) enqueue_pushable_dl_task(rq, p); } --=20 2.53.0.473.g4a7958ca14-goog