Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp221582pxb; Mon, 13 Sep 2021 17:32:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwPC/B4/O1+8h2vAbDnB2Mvas9r83Aai0yr3aFBywZwoS/0r9QnnzRiOX7xvP17C1IiPstg X-Received: by 2002:a05:6638:d85:: with SMTP id l5mr11992232jaj.2.1631579550399; Mon, 13 Sep 2021 17:32:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631579550; cv=none; d=google.com; s=arc-20160816; b=E8oi7aWO0Ayk3vT/WDcFWR9sMmBBJz7L4vlMfHbBMHCsQqCw2LN0daoODYWQTwsZuz HflZYocG3tL7urR2PIYkc0RhX+r9wL4Ih2FmWHmWCNsz1TXhIGcXODHSOFH65gbdPBUv eDUO1cDxuVabChZfy6gjJ8viKnVwiUgJtW12LD1ri07ZeA3bHKPZ8KyjkbvUlYye24Lf BZ41Bh96WJIzKI2Rq1WPHddMTbbzWSVBVkuhpEusIVTgZ64vKnOHu3BcUJLWEl4p7hvL AlmiLvOGAv9arCiv+UKLaLw3XRohTm8gvtuaLqpxPtSSyyBrPomI/Gpny9XCYaV646VH qxYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=YdFSBdXK4U5Ya9vOpA6iXo+EJM466bU25qqgfH6B+3g=; b=JBwJdIEVLFThGqjtlbU3yRPeEBTE8THT6CLdr+raVNRVmk6yE5AqJp1OK9jfCxTykX ATGk0N/SqEbG5EoAA3iedAyRwipTHOKoJKADUMipL1qL5W+Pl+1Xkm7aHILl91bIzJ29 b8Kx+RCRWf4SVp7z2ywjymMnVKfCjzf/b1wlHzc7ax420qKT32oINyJTI9wqwhMW46Q3 o6fnxgOdUuoiGrs9kGZ9H1wk0dsOy9kxjpVnLuNtkCye2kL50G/Zfy/KoQKgxl5NYtik gM98nX5WLK1PoqYK47gaqyihVk4f4xsfENyCSqoHW5O7+kwDlRQzNnJxW55DfYlPp0T9 9Lkg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=tZM22hFb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z17si8076696ils.47.2021.09.13.17.32.17; Mon, 13 Sep 2021 17:32:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=tZM22hFb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343696AbhIMO22 (ORCPT + 99 others); Mon, 13 Sep 2021 10:28:28 -0400 Received: from mail.kernel.org ([198.145.29.99]:42328 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344321AbhIMOWV (ORCPT ); Mon, 13 Sep 2021 10:22:21 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 44C8661B2F; Mon, 13 Sep 2021 13:47:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1631540836; bh=zLWtLF0bywMH2Z+U3Bn9vPzzjC/86zuSJmRnWCSfUk0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tZM22hFbgMRDrdp25fsRfD2c4dcYbzT4hgeGntWecgLhfM3wyr3NPpMOok7oePBqu JgMj44R61/1dyHXHxBLMrw4axUkAXeAhD198gDtMy0iIlQlj9AVqq8ioviGTHYWmeg hTZCql4m8ao9oDB0wp41Sw7FGdru+Dr8W0GPzcRA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Rick Yiu , Quentin Perret , "Peter Zijlstra (Intel)" , Qais Yousef , Dietmar Eggemann , Sasha Levin Subject: [PATCH 5.14 054/334] sched: Fix UCLAMP_FLAG_IDLE setting Date: Mon, 13 Sep 2021 15:11:48 +0200 Message-Id: <20210913131115.248111333@linuxfoundation.org> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20210913131113.390368911@linuxfoundation.org> References: <20210913131113.390368911@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Quentin Perret [ Upstream commit ca4984a7dd863f3e1c0df775ae3e744bff24c303 ] The UCLAMP_FLAG_IDLE flag is set on a runqueue when dequeueing the last uclamp active task (that is, when buckets.tasks reaches 0 for all buckets) to maintain the last uclamp.max and prevent blocked util from suddenly becoming visible. However, there is an asymmetry in how the flag is set and cleared which can lead to having the flag set whilst there are active tasks on the rq. Specifically, the flag is cleared in the uclamp_rq_inc() path, which is called at enqueue time, but set in uclamp_rq_dec_id() which is called both when dequeueing a task _and_ in the update_uclamp_active() path. As a result, when both uclamp_rq_{dec,ind}_id() are called from update_uclamp_active(), the flag ends up being set but not cleared, hence leaving the runqueue in a broken state. Fix this by clearing the flag in update_uclamp_active() as well. Fixes: e496187da710 ("sched/uclamp: Enforce last task's UCLAMP_MAX") Reported-by: Rick Yiu Signed-off-by: Quentin Perret Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Qais Yousef Tested-by: Dietmar Eggemann Link: https://lore.kernel.org/r/20210805102154.590709-2-qperret@google.com Signed-off-by: Sasha Levin --- kernel/sched/core.c | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index f3b27c6c5153..a2403432f3ab 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -1633,6 +1633,23 @@ static inline void uclamp_rq_dec(struct rq *rq, struct task_struct *p) uclamp_rq_dec_id(rq, p, clamp_id); } +static inline void uclamp_rq_reinc_id(struct rq *rq, struct task_struct *p, + enum uclamp_id clamp_id) +{ + if (!p->uclamp[clamp_id].active) + return; + + uclamp_rq_dec_id(rq, p, clamp_id); + uclamp_rq_inc_id(rq, p, clamp_id); + + /* + * Make sure to clear the idle flag if we've transiently reached 0 + * active tasks on rq. + */ + if (clamp_id == UCLAMP_MAX && (rq->uclamp_flags & UCLAMP_FLAG_IDLE)) + rq->uclamp_flags &= ~UCLAMP_FLAG_IDLE; +} + static inline void uclamp_update_active(struct task_struct *p) { @@ -1656,12 +1673,8 @@ uclamp_update_active(struct task_struct *p) * affecting a valid clamp bucket, the next time it's enqueued, * it will already see the updated clamp bucket value. */ - for_each_clamp_id(clamp_id) { - if (p->uclamp[clamp_id].active) { - uclamp_rq_dec_id(rq, p, clamp_id); - uclamp_rq_inc_id(rq, p, clamp_id); - } - } + for_each_clamp_id(clamp_id) + uclamp_rq_reinc_id(rq, p, clamp_id); task_rq_unlock(rq, p, &rf); } -- 2.30.2