Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2276245pxb; Thu, 11 Feb 2021 08:28:00 -0800 (PST) X-Google-Smtp-Source: ABdhPJx/3i+ZxnE1WmMwscLMMucqDujHBWYHLLQPhnd2LDkCHcQmxDovHHHOGMjLvs7azntzy8nb X-Received: by 2002:a17:906:5653:: with SMTP id v19mr9491773ejr.481.1613060879958; Thu, 11 Feb 2021 08:27:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613060879; cv=none; d=google.com; s=arc-20160816; b=Yj3cE8zyC9bfuiCmoHGfZ8gh4U4dOsn2TH5KGrAOutVQIVI+PbFYga6jEi8iIloFhk hEVenVCYP6yD7qahMoD/Hc7UtJUwHzU1ExQ0umLbIY3g0uRLG5O8owX5GDnoyqNe+39+ G67cVYTYh3LcAW0sQLJ+Mj/Z2+SAac8WWTJ1gy29wJT160/WsVO/bTt0gk7ZWAEGEnlU olefLNUqjSXt0p4hUf+GkU5S2Vu/viwm0Yon5nUhIBitoahZX9B8FCPP5eDOENOhUkmL YpFqxYOkTWGRjpkMPtsj/gcq2+Xtr4u+Ne3mvqTn8a8uZfi814IILM8T+8czWpsec2QH er1w== 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=NwRF6ITzRMjNfd5vMHX5PeZkK+JQK8diozMr0uN3I1w=; b=U3LxYY2y+PJxVfQHfJ6LGJURagC77V7KUdOab8aIarCDfvCYWnsx7zvz0PKezbIJcF f0oryzWCSdlzCNeeclX1zrEFzNWnClmVa8Vrf9YeVBrEQ6OhyGz194GrEZbtpEwmcpLd 47wwbPZ5qo07wuBcJh2G+cG/1zEOAbliuWfjUFuA8dBzeQQEOtM4s6Uq7ujeMxpc/8ub VLt0sFJF1Ww9ctDFhApLPbX+bZwtlrbK/y/3rWCt7lQapjznPn1HN0uGR1XMvotSB+L+ opx8c8/1Bl1NBVp/o5SXLMjoP0bsrXPdxysuyi5ytJCdmcnbAu3AkaqHIobH3eTMHMw6 5vTg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=GIod9L2K; 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 d4si3997912edu.106.2021.02.11.08.27.34; Thu, 11 Feb 2021 08:27:59 -0800 (PST) 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=GIod9L2K; 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 S230438AbhBKQ1A (ORCPT + 99 others); Thu, 11 Feb 2021 11:27:00 -0500 Received: from mail.kernel.org ([198.145.29.99]:53512 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231138AbhBKPYz (ORCPT ); Thu, 11 Feb 2021 10:24:55 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 2B4BB64DE9; Thu, 11 Feb 2021 15:03:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1613055823; bh=g0jnqO8DlA/7RA7rV5xrQmRpl8bFcYn5/QDQbmd3AsM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GIod9L2KmGUzKemgB67s7vFou2BtiU2QZ7Km0KGTHZdy7OSNa/fOOtJH36+2/DpEF 4HHiT/bcNsdj/dxIMTkPZ6mVYkLqWinhQzCVzlUQQe4mSMeZgeoUrMjr0hz3DY2Z9y 7KPIoLTLv1An2n3szXxU6crANF6WoJjHcjheWyWE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, David Collins , Mark Brown , Sasha Levin Subject: [PATCH 5.10 20/54] regulator: core: avoid regulator_resolve_supply() race condition Date: Thu, 11 Feb 2021 16:02:04 +0100 Message-Id: <20210211150153.763514141@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210211150152.885701259@linuxfoundation.org> References: <20210211150152.885701259@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: David Collins [ Upstream commit eaa7995c529b54d68d97a30f6344cc6ca2f214a7 ] The final step in regulator_register() is to call regulator_resolve_supply() for each registered regulator (including the one in the process of being registered). The regulator_resolve_supply() function first checks if rdev->supply is NULL, then it performs various steps to try to find the supply. If successful, rdev->supply is set inside of set_supply(). This procedure can encounter a race condition if two concurrent tasks call regulator_register() near to each other on separate CPUs and one of the regulators has rdev->supply_name specified. There is currently nothing guaranteeing atomicity between the rdev->supply check and set steps. Thus, both tasks can observe rdev->supply==NULL in their regulator_resolve_supply() calls. This then results in both creating a struct regulator for the supply. One ends up actually stored in rdev->supply and the other is lost (though still present in the supply's consumer_list). Here is a kernel log snippet showing the issue: [ 12.421768] gpu_cc_gx_gdsc: supplied by pm8350_s5_level [ 12.425854] gpu_cc_gx_gdsc: supplied by pm8350_s5_level [ 12.429064] debugfs: Directory 'regulator.4-SUPPLY' with parent '17a00000.rsc:rpmh-regulator-gfxlvl-pm8350_s5_level' already present! Avoid this race condition by holding the rdev->mutex lock inside of regulator_resolve_supply() while checking and setting rdev->supply. Signed-off-by: David Collins Link: https://lore.kernel.org/r/1610068562-4410-1-git-send-email-collinsd@codeaurora.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin --- drivers/regulator/core.c | 39 ++++++++++++++++++++++++++++----------- 1 file changed, 28 insertions(+), 11 deletions(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 42bbd99a36acf..2c31f04ff950f 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -1813,23 +1813,34 @@ static int regulator_resolve_supply(struct regulator_dev *rdev) { struct regulator_dev *r; struct device *dev = rdev->dev.parent; - int ret; + int ret = 0; /* No supply to resolve? */ if (!rdev->supply_name) return 0; - /* Supply already resolved? */ + /* Supply already resolved? (fast-path without locking contention) */ if (rdev->supply) return 0; + /* + * Recheck rdev->supply with rdev->mutex lock held to avoid a race + * between rdev->supply null check and setting rdev->supply in + * set_supply() from concurrent tasks. + */ + regulator_lock(rdev); + + /* Supply just resolved by a concurrent task? */ + if (rdev->supply) + goto out; + r = regulator_dev_lookup(dev, rdev->supply_name); if (IS_ERR(r)) { ret = PTR_ERR(r); /* Did the lookup explicitly defer for us? */ if (ret == -EPROBE_DEFER) - return ret; + goto out; if (have_full_constraints()) { r = dummy_regulator_rdev; @@ -1837,15 +1848,18 @@ static int regulator_resolve_supply(struct regulator_dev *rdev) } else { dev_err(dev, "Failed to resolve %s-supply for %s\n", rdev->supply_name, rdev->desc->name); - return -EPROBE_DEFER; + ret = -EPROBE_DEFER; + goto out; } } if (r == rdev) { dev_err(dev, "Supply for %s (%s) resolved to itself\n", rdev->desc->name, rdev->supply_name); - if (!have_full_constraints()) - return -EINVAL; + if (!have_full_constraints()) { + ret = -EINVAL; + goto out; + } r = dummy_regulator_rdev; get_device(&r->dev); } @@ -1859,7 +1873,8 @@ static int regulator_resolve_supply(struct regulator_dev *rdev) if (r->dev.parent && r->dev.parent != rdev->dev.parent) { if (!device_is_bound(r->dev.parent)) { put_device(&r->dev); - return -EPROBE_DEFER; + ret = -EPROBE_DEFER; + goto out; } } @@ -1867,13 +1882,13 @@ static int regulator_resolve_supply(struct regulator_dev *rdev) ret = regulator_resolve_supply(r); if (ret < 0) { put_device(&r->dev); - return ret; + goto out; } ret = set_supply(rdev, r); if (ret < 0) { put_device(&r->dev); - return ret; + goto out; } /* @@ -1886,11 +1901,13 @@ static int regulator_resolve_supply(struct regulator_dev *rdev) if (ret < 0) { _regulator_put(rdev->supply); rdev->supply = NULL; - return ret; + goto out; } } - return 0; +out: + regulator_unlock(rdev); + return ret; } /* Internal regulator request function */ -- 2.27.0