Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp36801pxb; Tue, 12 Apr 2022 16:06:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw49oNBTGqjGGBJG07iFrhxoWc88mNrZca4ybrrHOKM/oIsKamPuYnHQQouaJniBkpB1lgk X-Received: by 2002:a63:485d:0:b0:39d:8ebf:9acf with SMTP id x29-20020a63485d000000b0039d8ebf9acfmr5127349pgk.351.1649804789301; Tue, 12 Apr 2022 16:06:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649804789; cv=none; d=google.com; s=arc-20160816; b=SOnFtdW42hqgYzQCVgZRVSQAkSgFbFbP9M1tTLZVLJjO/exO0Dq2V3RIK0kliSNOwQ XWMSdxOzu8jO26jEel4o3WDmwgyg4CPl1euLUlKJF0NPEF6hBYyaNx5ncT0h6qvdfPlN q1SAoBdH1BFiCLc3tpl/jzw2o52309L5R0PJ0HORZLpjvlnooc7zZafni/No1ylGMpfr JCaG0ldRqHcdooRWix6qrK5ZfS9rGnhGgi3g9jE3XTrmcIDJMD1NvuwbrN2WzjjkLnKG HWoDFasVeyfN+2w+PMIx7MUzu3XfxdXrFxrFSWEirFpO+BgYfT2m/HVRlFUbLJENxQrB qw/g== 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=DhjaLxUqkq7V/5Ee8FtSqo59CsVLEvVC+Uy3DjAd1gE=; b=ORO4Qe2VJk6wrFwxRC1ewkbL4t7lmG1eCtB7Squn7IvtAeqKwbHdTxfILxOyv/LYxS YwR9cnoY9YDFlqwB2CAicFqIa2WaXn92kGDrpN2vxbgQpxHrgOLzj0OFwNTxuPgkNcuX KR2WD9Es9954eT59lcyPi4rK1UxnIFRg1AVsfRSnFs1u/FHTMYzPKMmI54uheGYt4uFo /K+GVtVESQRTgpSywWlWs99zDXKeQxK5GMKXNLmhushat5PGqInbivsZwYXFb/jW8seo U2w8DFLjS7Kfy/+k1qL4CppZhEotbGF3rjTxALW31+ahoyHfVG0veh4qaFEp/f2cDfHE Q6HQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=BscrU6n2; 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 oj1-20020a17090b4d8100b001cba0b29970si7381658pjb.96.2022.04.12.16.06.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 16:06:29 -0700 (PDT) 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=BscrU6n2; 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 out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E16A41F1606; Tue, 12 Apr 2022 14:48:39 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1389041AbiDLJXU (ORCPT + 99 others); Tue, 12 Apr 2022 05:23:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45786 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357318AbiDLHj7 (ORCPT ); Tue, 12 Apr 2022 03:39:59 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 59587245B7; Tue, 12 Apr 2022 00:15:06 -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 E869C61708; Tue, 12 Apr 2022 07:15:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 049E6C385A1; Tue, 12 Apr 2022 07:15:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649747705; bh=U5BKBINZqkY8YG7da1WWh8GmjHRsCM7kZc6c8O3P0Vk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BscrU6n2COYk9Lf8Omsw3TzV45pUc2iBP9uzBLZlHGbmyfCBwr+HvzwXz4XaWXkcU ZTuD/ux09uJ4LK/fURZoLJX2yvRk55J1bJL13aMNx4sw7jRHdRWCmpW9jS/6RFMseI MsWr6dL0gzWAfFw9WjjshdKxJHCbEWsmMeB3a85w= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Maxime Ripard , Stephen Boyd , Sasha Levin Subject: [PATCH 5.17 176/343] clk: Enforce that disjoints limits are invalid Date: Tue, 12 Apr 2022 08:29:54 +0200 Message-Id: <20220412062956.446464118@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220412062951.095765152@linuxfoundation.org> References: <20220412062951.095765152@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=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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: Maxime Ripard [ Upstream commit 10c46f2ea914202482d19cf80dcc9c321c9ff59b ] If we were to have two users of the same clock, doing something like: clk_set_rate_range(user1, 1000, 2000); clk_set_rate_range(user2, 3000, 4000); The second call would fail with -EINVAL, preventing from getting in a situation where we end up with impossible limits. However, this is never explicitly checked against and enforced, and works by relying on an undocumented behaviour of clk_set_rate(). Indeed, on the first clk_set_rate_range will make sure the current clock rate is within the new range, so it will be between 1000 and 2000Hz. On the second clk_set_rate_range(), it will consider (rightfully), that our current clock is outside of the 3000-4000Hz range, and will call clk_core_set_rate_nolock() to set it to 3000Hz. clk_core_set_rate_nolock() will then call clk_calc_new_rates() that will eventually check that our rate 3000Hz rate is outside the min 3000Hz max 2000Hz range, will bail out, the error will propagate and we'll eventually return -EINVAL. This solely relies on the fact that clk_calc_new_rates(), and in particular clk_core_determine_round_nolock(), won't modify the new rate allowing the error to be reported. That assumption won't be true for all drivers, and most importantly we'll break that assumption in a later patch. It can also be argued that we shouldn't even reach the point where we're calling clk_core_set_rate_nolock(). Let's make an explicit check for disjoints range before we're doing anything. Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20220225143534.405820-4-maxime@cerno.tech Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin --- drivers/clk/clk.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 01b64b962e76..2fdfce116087 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -632,6 +632,24 @@ static void clk_core_get_boundaries(struct clk_core *core, *max_rate = min(*max_rate, clk_user->max_rate); } +static bool clk_core_check_boundaries(struct clk_core *core, + unsigned long min_rate, + unsigned long max_rate) +{ + struct clk *user; + + lockdep_assert_held(&prepare_lock); + + if (min_rate > core->max_rate || max_rate < core->min_rate) + return false; + + hlist_for_each_entry(user, &core->clks, clks_node) + if (min_rate > user->max_rate || max_rate < user->min_rate) + return false; + + return true; +} + void clk_hw_set_rate_range(struct clk_hw *hw, unsigned long min_rate, unsigned long max_rate) { @@ -2348,6 +2366,11 @@ int clk_set_rate_range(struct clk *clk, unsigned long min, unsigned long max) clk->min_rate = min; clk->max_rate = max; + if (!clk_core_check_boundaries(clk->core, min, max)) { + ret = -EINVAL; + goto out; + } + rate = clk_core_get_rate_nolock(clk->core); if (rate < min || rate > max) { /* @@ -2376,6 +2399,7 @@ int clk_set_rate_range(struct clk *clk, unsigned long min, unsigned long max) } } +out: if (clk->exclusive_count) clk_core_rate_protect(clk->core); -- 2.35.1