Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp2835179pxv; Mon, 12 Jul 2021 03:07:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxSpMAkKYrksfW/nwxokh0LEVElX45FzqNQW/DmmiAvSJJ1jZkQdfgXcgnTkQOTBd91EEVM X-Received: by 2002:a5d:8747:: with SMTP id k7mr40680198iol.83.1626084442230; Mon, 12 Jul 2021 03:07:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626084442; cv=none; d=google.com; s=arc-20160816; b=TGOiX20McpD4O4p2AOaQpHxdXWdZu0fo9V53MVMRNMMnfG+S1dSof6ahQRlgRug+st LAQU3YV7nQGBkWyQk0qbYWy5wJsMXPSFxLc2xNdkNG6p3d++hKmmvKlp1IyuVFEdJ4Ry I33UBTqAmR5LKska9DEGAVwhrqROx9udvcR5FhEKySXZdNpkOBPfj3S00gyFmL2adwoX gJ8i6MXAYsIvcuVBRjiS7wAmfKy6Ai5VqjcRLEVvPwV4omiRu7a57mLxmzHpAETaXLsO oDKRbmiHIBQyRl95KiqM5kddwGDo+SFu6ER4WlfkNz5hglYXK52EGyXkx43Y5tWYrkGN k+ig== 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=gtqRCSZna2qU3TPuBlukOSQqbQ68PG81TyQfEy7Ff5w=; b=kKjuBl3OvCdLR8GqT/a6uzC6wWpJE+wzV/4EZUBJFUqcqDTUAmar4a1YA7ki1S2KGh gX0uZ7Z/I9QHwGXX9ylhITKWlNBwsuiHSHFoPC8TEMWD4Ij6X1uh26alxrTLhOqE0/vy MM5/BXrJkMlr2m5Kyzc94IxQ/iUcPNDCB9a6YTNQWjNVk6o2ITO9z86wtfrz+U5+SO7u Yt/9xGfVO8V4uJ4Cg7Fe/x757Od/K3lSAuCcs2Ao6g3pYOirJthidvzhIElVWU62hJqH GmElxJ2uNktq4gkjD0VK5X051lmPk6avw2uY2d9w2nA+iklxU0pecUUwDiBHEdndrwB7 jCdw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=WUivJgfg; 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 p31si19418384jac.95.2021.07.12.03.07.10; Mon, 12 Jul 2021 03:07:22 -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=WUivJgfg; 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 S1345642AbhGLHi5 (ORCPT + 99 others); Mon, 12 Jul 2021 03:38:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:42134 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244185AbhGLHK3 (ORCPT ); Mon, 12 Jul 2021 03:10:29 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id C1060613D4; Mon, 12 Jul 2021 07:07:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1626073624; bh=h/Ohe38gD02ghfKe08hLeUHUHkf5p7Y1xWoRa6HSz6c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WUivJgfgzyA7qC7AeAoOMysz8119fFSmzeQZ8oTOxTpVFlZiJonB23ffDqPfidUBn 0/PXTXONFdV3Q9VG74OgW2UCCV97E1BedoHnDRLFFDaw3iwqEdyAdX0h8fWglDkv4z w9gEabKw2KhLV+t/rA3RuTydXKX70o41bLxkxbjg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Quentin Perret , Qais Yousef , "Peter Zijlstra (Intel)" , Sasha Levin Subject: [PATCH 5.12 261/700] sched/uclamp: Fix locking around cpu_util_update_eff() Date: Mon, 12 Jul 2021 08:05:44 +0200 Message-Id: <20210712061003.930651224@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210712060924.797321836@linuxfoundation.org> References: <20210712060924.797321836@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: Qais Yousef [ Upstream commit 93b73858701fd01de26a4a874eb95f9b7156fd4b ] cpu_cgroup_css_online() calls cpu_util_update_eff() without holding the uclamp_mutex or rcu_read_lock() like other call sites, which is a mistake. The uclamp_mutex is required to protect against concurrent reads and writes that could update the cgroup hierarchy. The rcu_read_lock() is required to traverse the cgroup data structures in cpu_util_update_eff(). Surround the caller with the required locks and add some asserts to better document the dependency in cpu_util_update_eff(). Fixes: 7226017ad37a ("sched/uclamp: Fix a bug in propagating uclamp value in new cgroups") Reported-by: Quentin Perret Signed-off-by: Qais Yousef Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210510145032.1934078-3-qais.yousef@arm.com Signed-off-by: Sasha Levin --- kernel/sched/core.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 3fe7daf9d31d..f59166fe499a 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -8693,7 +8693,11 @@ static int cpu_cgroup_css_online(struct cgroup_subsys_state *css) #ifdef CONFIG_UCLAMP_TASK_GROUP /* Propagate the effective uclamp value for the new group */ + mutex_lock(&uclamp_mutex); + rcu_read_lock(); cpu_util_update_eff(css); + rcu_read_unlock(); + mutex_unlock(&uclamp_mutex); #endif return 0; @@ -8783,6 +8787,9 @@ static void cpu_util_update_eff(struct cgroup_subsys_state *css) enum uclamp_id clamp_id; unsigned int clamps; + lockdep_assert_held(&uclamp_mutex); + SCHED_WARN_ON(!rcu_read_lock_held()); + css_for_each_descendant_pre(css, top_css) { uc_parent = css_tg(css)->parent ? css_tg(css)->parent->uclamp : NULL; -- 2.30.2