Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1572235pxb; Tue, 8 Feb 2022 22:42:21 -0800 (PST) X-Google-Smtp-Source: ABdhPJwFXc+VVX281R9BvX7RPoSpGkI3CH/RvAvn3pxieH7bZkTX3j4xlMK1jvJvyXHroSxVmAQ+ X-Received: by 2002:a05:6a00:cc8:: with SMTP id b8mr872016pfv.64.1644388941417; Tue, 08 Feb 2022 22:42:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644388941; cv=none; d=google.com; s=arc-20160816; b=MmA85SGzt68vZJWj7nIfjkYRTQdEY7gyoOkUNAuRUYjOqTez3DzjE5EDQYKRQQvUNm 0NxjfBi7WMBshLhknCjY2dKHAVql8Sf7vW7kLtauzvODjtDQ1ZX5eWVQxEIbHC3ML2TG XzS6/ICCb6npUxvFzBrpPjX6bU40bXlLbVj0uhWlLOi/5FUnbRis8jZ/3ldbxs3UgG76 PNvw2zu3i4iHZ2AY3/uHAarQK0ZKti1JULoqzMuDxGcCVZb4Mq1gUeRi9BbXRmZkE/13 D2Ts59616sEe4f1Y2YVJSO5wSTo2D9i/eMtGYIqvB/webcBQ+H9l7r5/l5f1+KMaXo/0 vUkg== 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=WYWEi/GjmSKvDDki77un9rvqVH3k7h0v8PwPWEU9GqE=; b=JsKXe99AN9t/ZdSm00gYFKS4NdclBEHI3qDgOG/L07WgYJzc7l7KT3VOAnik8lOgyM sKRkhed787ff4NReqwb9FZo22+uypOgkRjoHrGPaqktbs2spDd0ZslR29yknzg4MFhwj hC5HrYQvTazPME4rbRlFrp5uHIIAzHhMkkSQouU/FZTxlTse4v7SAb3TScvRp8X+yDeJ 6pJqWq9D3EQdCzwJGNHw+w0q2h1+eB26qMIehJMq+lf13rbdd16cNP6eW5DkXdrmr3fm 3JuEVohVqrdEnfXzEpBX/+olNDM8zV70mwpK/DGqNKI+MGG0QQ1duohnawltsHMUEixa LOEQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=lyIW1SVL; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id e16si515708plh.210.2022.02.08.22.42.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Feb 2022 22:42:21 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=lyIW1SVL; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7568BC02B5D8; Tue, 8 Feb 2022 22:26:43 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1390661AbiBGL5L (ORCPT + 99 others); Mon, 7 Feb 2022 06:57:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44654 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1385224AbiBGLbY (ORCPT ); Mon, 7 Feb 2022 06:31:24 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 73786C02C461; Mon, 7 Feb 2022 03:29:43 -0800 (PST) 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 119A260A69; Mon, 7 Feb 2022 11:29:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E2CFBC004E1; Mon, 7 Feb 2022 11:29:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1644233382; bh=qVNKeck0zmBC2NlbwYsQU2xFOx29BT7tvNk9RAbYvl8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lyIW1SVLv4iMkO1aBzTC7qAJ2XPhBJzLtEGc0ei0+2eJPAsrlOSsFwUBrhNsmgExi dOqsLV2z5XYofUAZncWAT0wZhAha8ERoF2IoiGtMJly534aJ9P/wFAizYqLayXn/Oo YKrYG9JBOlIDpVon49sM5NQOEWOIWz0y2yio6lxM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Waiman Long , Phil Auld , Tejun Heo Subject: [PATCH 5.15 105/110] cgroup/cpuset: Fix "suspicious RCU usage" lockdep warning Date: Mon, 7 Feb 2022 12:07:18 +0100 Message-Id: <20220207103805.944986607@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220207103802.280120990@linuxfoundation.org> References: <20220207103802.280120990@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Waiman Long commit 2bdfd2825c9662463371e6691b1a794e97fa36b4 upstream. It was found that a "suspicious RCU usage" lockdep warning was issued with the rcu_read_lock() call in update_sibling_cpumasks(). It is because the update_cpumasks_hier() function may sleep. So we have to release the RCU lock, call update_cpumasks_hier() and reacquire it afterward. Also add a percpu_rwsem_assert_held() in update_sibling_cpumasks() instead of stating that in the comment. Fixes: 4716909cc5c5 ("cpuset: Track cpusets that use parent's effective_cpus") Signed-off-by: Waiman Long Tested-by: Phil Auld Reviewed-by: Phil Auld Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman --- kernel/cgroup/cpuset.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -1512,10 +1512,15 @@ static void update_sibling_cpumasks(stru struct cpuset *sibling; struct cgroup_subsys_state *pos_css; + percpu_rwsem_assert_held(&cpuset_rwsem); + /* * Check all its siblings and call update_cpumasks_hier() * if their use_parent_ecpus flag is set in order for them * to use the right effective_cpus value. + * + * The update_cpumasks_hier() function may sleep. So we have to + * release the RCU read lock before calling it. */ rcu_read_lock(); cpuset_for_each_child(sibling, pos_css, parent) { @@ -1523,8 +1528,13 @@ static void update_sibling_cpumasks(stru continue; if (!sibling->use_parent_ecpus) continue; + if (!css_tryget_online(&sibling->css)) + continue; + rcu_read_unlock(); update_cpumasks_hier(sibling, tmp); + rcu_read_lock(); + css_put(&sibling->css); } rcu_read_unlock(); }