From nobody Thu Dec 18 00:45:40 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 40F5C125D5 for ; Wed, 24 Jul 2024 14:23:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721831001; cv=none; b=tRRQfoxQtMlKzteyP0uwk9dfV2IYicwinOnkNngijwNmx40VvSAZy0RpLS6G+2BsQrjWwrGolS4hr8yCaZzA5xBb7vF0jo3cTTnZwpGwFvpo96yW478ydg2APjE5c9UlTRDOOqqwFpRYMKNyJmJbGHlfQkxfUnpaCSytLhp3rHA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721831001; c=relaxed/simple; bh=HJ9/G39Nq4j+yKp43ZVY8GgRxRVgiJxdviG+lkjVV1U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=W2PtLKIaTG3TwnME/L22dxhDbvPQe6Gw7yXiBhXJwPJzA48PQ5hR+xsBEHCsO+tl4azjYDL6XoN3kFL/5UURaB4jU/vb/yZDkJE2dVOvXbTUW1XpvvJLxYC24gAydkDtDeRh1/Mz2Lu0afduilnNkWGzQuEdkCPj4Pimur91AIg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=E15sFLLV; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="E15sFLLV" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1721830999; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DYd8+46ttGqTNWLBCR4RO/uu/xWjj2COua22/d9i+ZA=; b=E15sFLLVYHTz1s3oPywUgTFvSeP2PojqEuXpjyFUWUwuvpMsy9HK2OhICB9b7IcAS+oNT1 vRzgg+7tawZF1nSX7sJQ3bq2ZUO5zpnUBu6IzEiZUTQ3rP+cfBYRgOi6xjFPquHkZT/Uq7 XIbOsIiLMrrxFxGQf0kRflDvSqeqQ6w= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-556-mL8kTLR1PDKIQhTBtWsuTg-1; Wed, 24 Jul 2024 10:23:15 -0400 X-MC-Unique: mL8kTLR1PDKIQhTBtWsuTg-1 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 26B231955F56; Wed, 24 Jul 2024 14:23:12 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.96.134.38]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 8B2E81955F65; Wed, 24 Jul 2024 14:23:07 +0000 (UTC) From: Wander Lairson Costa To: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , linux-kernel@vger.kernel.org (open list:SCHEDULER) Cc: Wander Lairson Costa Subject: [PATCH v2 1/2] sched/deadline: Fix warning in migrate_enable for boosted tasks Date: Wed, 24 Jul 2024 11:22:47 -0300 Message-ID: <20240724142253.27145-2-wander@redhat.com> In-Reply-To: <20240724142253.27145-1-wander@redhat.com> References: <20240724142253.27145-1-wander@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 Content-Type: text/plain; charset="utf-8" When running the following command: while true; do stress-ng --cyclic 30 --timeout 30s --minimize --quiet done a warning is eventually triggered: WARNING: CPU: 43 PID: 2848 at kernel/sched/deadline.c:794 setup_new_dl_entity+0x13e/0x180 ... Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? enqueue_dl_entity+0x631/0x6e0 ? setup_new_dl_entity+0x13e/0x180 ? __warn+0x7e/0xd0 ? report_bug+0x11a/0x1a0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 enqueue_dl_entity+0x631/0x6e0 enqueue_task_dl+0x7d/0x120 __do_set_cpus_allowed+0xe3/0x280 __set_cpus_allowed_ptr_locked+0x140/0x1d0 __set_cpus_allowed_ptr+0x54/0xa0 migrate_enable+0x7e/0x150 rt_spin_unlock+0x1c/0x90 group_send_sig_info+0xf7/0x1a0 ? kill_pid_info+0x1f/0x1d0 kill_pid_info+0x78/0x1d0 kill_proc_info+0x5b/0x110 __x64_sys_kill+0x93/0xc0 do_syscall_64+0x5c/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f0dab31f92b This warning occurs because set_cpus_allowed dequeues and enqueues tasks with the ENQUEUE_RESTORE flag set. If the task is boosted, the warning is triggered. A boosted task already had its parameters set by rt_mutex_setprio, and a new call to setup_new_dl_entity is unnecessary, hence the WARN_ON call. Check if we are requeueing a boosted task and avoid calling setup_new_dl_entity if that's the case. Signed-off-by: Wander Lairson Costa Fixes: 295d6d5e3736 ("sched/deadline: Fix switching to -deadline") Acked-by: Juri Lelli --- The initial idea for this fix was to introduce another ENQUEUE flag, ENQUEUE_SET_CPUS_ALLOWED. When this flag was set, the deadline scheduler would bypass the call to setup_new_dl_entity, regardless of whether the task was boosted. However, this idea was abandoned due to the presence of other DEQUEUE_SAVE/ENQUEUE_RESTORE pairs in the code. Ultimately, a simpler approach was chosen, which achieves the same practical effects without the need to create an additional flag for enqueue_task. Signed-off-by: Wander Lairson Costa --- kernel/sched/deadline.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index f59e5c19d944..312e8fa7ce94 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -1753,6 +1753,7 @@ enqueue_dl_entity(struct sched_dl_entity *dl_se, int = flags) } else if (flags & ENQUEUE_REPLENISH) { replenish_dl_entity(dl_se); } else if ((flags & ENQUEUE_RESTORE) && + !is_dl_boosted(dl_se) && dl_time_before(dl_se->deadline, rq_clock(rq_of_dl_se(dl_se)))) { setup_new_dl_entity(dl_se); } --=20 2.45.2 From nobody Thu Dec 18 00:45:40 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A5D2315A868 for ; Wed, 24 Jul 2024 14:23:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721831009; cv=none; b=toCXk2QnyUXk8ss9agX3CwIeeCzJONS1EsVGdmxFRhLfHnMmFt+1GwWt9gti7yY7YbgFA6WVAjLipM+hOAbng8DhjKkguELpWGcVL10zXor5Tft02wKLNysIMPul8ibkvLNrUo97muEn3sD9OKJSWjWyHXp2uGHrjDpYH/XORwA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721831009; c=relaxed/simple; bh=s4HNljaPZJLJD6YDsI7FLSF9XPk6iswpMqvouyoqiVo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Fg6Fy9F8dZJkkAOJJpsQ4M5o3KzlIMaU1BFR7mlgB6cP+B1dbjBc7oaDVGfwPcYCbiNnvXWysuqDNfYC1r5ExPWs3NOkxof8y3s+3TMPx8qITm7stJrklk/sYNMGSdmF/F6Y62tt2oot8g9qyBi2JLSKNFGULIZdMrhFUHrcOiU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=UcDT1P7w; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="UcDT1P7w" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1721831006; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZK+LHXm7qy0Qg5Y629tT+uBJ6vtvH0lHMF8fm1/ksuU=; b=UcDT1P7wiMaoVlN7bBYeMS92203AGOrv59mLFSRRFZOx/eEDBG+wcyzrMdlhFNPykEan7w 17hXET31h6Mo2FCliMu1gpwwvk/AvK3B5TlNe1Spc/+rhsSJP1PEmsUSjrJh6ULjowADzG i1kL5mrAFY/gvng4shqG2+hIvBc6cUk= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-376-mZeYtixNODibNF_EnDzVTg-1; Wed, 24 Jul 2024 10:23:21 -0400 X-MC-Unique: mZeYtixNODibNF_EnDzVTg-1 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2084B1955BF2; Wed, 24 Jul 2024 14:23:18 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.96.134.38]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id ADC9219560AE; Wed, 24 Jul 2024 14:23:13 +0000 (UTC) From: Wander Lairson Costa To: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , linux-kernel@vger.kernel.org (open list:SCHEDULER) Cc: Wander Lairson Costa Subject: [PATCH v2 2/2] sched/deadline: Consolidate Timer Cancellation Date: Wed, 24 Jul 2024 11:22:48 -0300 Message-ID: <20240724142253.27145-3-wander@redhat.com> In-Reply-To: <20240724142253.27145-1-wander@redhat.com> References: <20240724142253.27145-1-wander@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 Content-Type: text/plain; charset="utf-8" After commit b58652db66c9 ("sched/deadline: Fix task_struct reference leak"), I identified additional calls to hrtimer_try_to_cancel that might also require a dl_server check. It remains unclear whether this omission was intentional or accidental in those contexts. This patch consolidates the timer cancellation logic into dedicated functions, ensuring consistent behavior across all calls. Additionally, it reduces code duplication and improves overall code cleanliness. Note the use of the __always_inline keyword. In some instances, we have a task_struct pointer, dereference the dl member, and then use the container_of macro to retrieve the task_struct pointer again. By inlining the code, the compiler can potentially optimize out this redundant round trip. Signed-off-by: Wander Lairson Costa Acked-by: Juri Lelli --- kernel/sched/deadline.c | 44 ++++++++++++++++++++++++++--------------- 1 file changed, 28 insertions(+), 16 deletions(-) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 312e8fa7ce94..b509ac4f3f6d 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -320,6 +320,29 @@ void sub_running_bw(struct sched_dl_entity *dl_se, str= uct dl_rq *dl_rq) __sub_running_bw(dl_se->dl_bw, dl_rq); } =20 +static __always_inline +void cancel_dl_timer(struct sched_dl_entity *dl_se, struct hrtimer *timer) +{ + /* + * If the timer callback was running (hrtimer_try_to_cancel =3D=3D -1), + * it will eventually call put_task_struct(). + */ + if (hrtimer_try_to_cancel(timer) =3D=3D 1 && !dl_server(dl_se)) + put_task_struct(dl_task_of(dl_se)); +} + +static __always_inline +void cancel_replenish_timer(struct sched_dl_entity *dl_se) +{ + cancel_dl_timer(dl_se, &dl_se->dl_timer); +} + +static __always_inline +void cancel_inactive_timer(struct sched_dl_entity *dl_se) +{ + cancel_dl_timer(dl_se, &dl_se->inactive_timer); +} + static void dl_change_utilization(struct task_struct *p, u64 new_bw) { struct rq *rq; @@ -340,8 +363,7 @@ static void dl_change_utilization(struct task_struct *p= , u64 new_bw) * will not touch the rq's active utilization, * so we are still safe. */ - if (hrtimer_try_to_cancel(&p->dl.inactive_timer) =3D=3D 1) - put_task_struct(p); + cancel_inactive_timer(&p->dl); } __sub_rq_bw(p->dl.dl_bw, &rq->dl); __add_rq_bw(new_bw, &rq->dl); @@ -490,10 +512,7 @@ static void task_contending(struct sched_dl_entity *dl= _se, int flags) * will not touch the rq's active utilization, * so we are still safe. */ - if (hrtimer_try_to_cancel(&dl_se->inactive_timer) =3D=3D 1) { - if (!dl_server(dl_se)) - put_task_struct(dl_task_of(dl_se)); - } + cancel_inactive_timer(dl_se); } else { /* * Since "dl_non_contending" is not set, the @@ -1805,13 +1824,8 @@ static void enqueue_task_dl(struct rq *rq, struct ta= sk_struct *p, int flags) * The replenish timer needs to be canceled. No * problem if it fires concurrently: boosted threads * are ignored in dl_task_timer(). - * - * If the timer callback was running (hrtimer_try_to_cancel =3D=3D -1), - * it will eventually call put_task_struct(). */ - if (hrtimer_try_to_cancel(&p->dl.dl_timer) =3D=3D 1 && - !dl_server(&p->dl)) - put_task_struct(p); + cancel_replenish_timer(&p->dl); p->dl.dl_throttled =3D 0; } } else if (!dl_prio(p->normal_prio)) { @@ -1976,8 +1990,7 @@ static void migrate_task_rq_dl(struct task_struct *p,= int new_cpu __maybe_unused * will not touch the rq's active utilization, * so we are still safe. */ - if (hrtimer_try_to_cancel(&p->dl.inactive_timer) =3D=3D 1) - put_task_struct(p); + cancel_inactive_timer(&p->dl); } sub_rq_bw(&p->dl, &rq->dl); rq_unlock(rq, &rf); @@ -2732,8 +2745,7 @@ static void switched_from_dl(struct rq *rq, struct ta= sk_struct *p) */ static void switched_to_dl(struct rq *rq, struct task_struct *p) { - if (hrtimer_try_to_cancel(&p->dl.inactive_timer) =3D=3D 1) - put_task_struct(p); + cancel_inactive_timer(&p->dl); =20 /* * In case a task is setscheduled to SCHED_DEADLINE we need to keep --=20 2.45.2