From nobody Wed Sep 3 01:54:00 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A36DC38145 for ; Fri, 2 Sep 2022 12:30:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236048AbiIBMaG (ORCPT ); Fri, 2 Sep 2022 08:30:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36292 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236610AbiIBM2s (ORCPT ); Fri, 2 Sep 2022 08:28:48 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A4BB728716; Fri, 2 Sep 2022 05:25:02 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5B18762159; Fri, 2 Sep 2022 12:25:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 625C5C433C1; Fri, 2 Sep 2022 12:25:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121501; bh=U7GMaY2it9Z4WBOXUdiR9o362PqChtpkJaBmnyMrYZA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CQsRf3uzB6mh2SvFuIfC002gEiIkLmHhyV73CVS1qzC5lkoswzclCeoOkSR9n6nGJ dkHs8r67qvxCApGjP1aEbr0pcU6Dk3po/3YyuErNvJ9D96LjQNfQp4zwN4xmbmpXrN 7WOj3g1fHzJKcYXLauJ7dQLW03hV7jH+lxA5nDAY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "srivatsab@vmware.com, srivatsa@csail.mit.edu, akaher@vmware.com, amakhalov@vmware.com, vsirnapalli@vmware.com, sturlapati@vmware.com, bordoloih@vmware.com, keerthanak@vmware.com, Ankit Jain" , Mark Simmons , Daniel Bristot de Oliveira , "Peter Zijlstra (Intel)" , Juri Lelli , Ankit Jain Subject: [PATCH 4.19 05/56] sched/deadline: Unthrottle PI boosted threads while enqueuing Date: Fri, 2 Sep 2022 14:18:25 +0200 Message-Id: <20220902121400.390643885@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121400.219861128@linuxfoundation.org> References: <20220902121400.219861128@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Daniel Bristot de Oliveira commit feff2e65efd8d84cf831668e182b2ce73c604bbb upstream. stress-ng has a test (stress-ng --cyclic) that creates a set of threads under SCHED_DEADLINE with the following parameters: dl_runtime =3D 10000 (10 us) dl_deadline =3D 100000 (100 us) dl_period =3D 100000 (100 us) These parameters are very aggressive. When using a system without HRTICK set, these threads can easily execute longer than the dl_runtime because the throttling happens with 1/HZ resolution. During the main part of the test, the system works just fine because the workload does not try to run over the 10 us. The problem happens at the end of the test, on the exit() path. During exit(), the threads need to do some cleanups that require real-time mutex locks, mainly those related to memory management, resulting in this scenario: Note: locks are rt_mutexes... ------------------------------------------------------------------------ TASK A: TASK B: TASK C: activation activation activation lock(a): OK! lock(b): OK! lock(a) -> block (task A owns it) -> self notice/set throttled +--< -> arm replenished timer | switch-out | lock(b) | -> B prio> | -> boost TASK B | unlock(a) switch-out | -> handle lock a to B | -> wakeup(B) | -> B is throttled: | -> do not enqueue | switch-out | | +---------------------> replenishment timer -> TASK B is boosted: -> do not enqueue ------------------------------------------------------------------------ BOOM: TASK B is runnable but !enqueued, holding TASK C: the system crashes with hung task C. This problem is avoided by removing the throttle state from the boosted thread while boosting it (by TASK A in the example above), allowing it to be queued and run boosted. The next replenishment will take care of the runtime overrun, pushing the deadline further away. See the "while (dl_se->runtime <=3D 0)" on replenish_dl_entity() for more information. Reported-by: Mark Simmons Signed-off-by: Daniel Bristot de Oliveira Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Juri Lelli Tested-by: Mark Simmons Link: https://lkml.kernel.org/r/5076e003450835ec74e6fa5917d02c4fa41687e6.16= 00170294.git.bristot@redhat.com [Ankit: Regenerated the patch for v4.19.y] Signed-off-by: Ankit Jain Signed-off-by: Greg Kroah-Hartman --- kernel/sched/deadline.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -1484,6 +1484,27 @@ static void enqueue_task_dl(struct rq *r */ if (pi_task && dl_prio(pi_task->normal_prio) && p->dl.dl_boosted) { pi_se =3D &pi_task->dl; + /* + * Because of delays in the detection of the overrun of a + * thread's runtime, it might be the case that a thread + * goes to sleep in a rt mutex with negative runtime. As + * a consequence, the thread will be throttled. + * + * While waiting for the mutex, this thread can also be + * boosted via PI, resulting in a thread that is throttled + * and boosted at the same time. + * + * In this case, the boost overrides the throttle. + */ + if (p->dl.dl_throttled) { + /* + * The replenish timer needs to be canceled. No + * problem if it fires concurrently: boosted threads + * are ignored in dl_task_timer(). + */ + hrtimer_try_to_cancel(&p->dl.dl_timer); + p->dl.dl_throttled =3D 0; + } } else if (!dl_prio(p->normal_prio)) { /* * Special case in which we have a !SCHED_DEADLINE task