Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2265002pxb; Thu, 11 Feb 2021 08:14:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJwpESUci6bVHxB4VDFJWNCrdHPhHu2Pp195oSfGCr1bLObCeS2JrbzxnBUwnnI9y0TgD9wf X-Received: by 2002:a17:906:d922:: with SMTP id rn2mr9427520ejb.414.1613060055743; Thu, 11 Feb 2021 08:14:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613060055; cv=none; d=google.com; s=arc-20160816; b=Elzp6DiQvBBRVe0dFlMlNzBoicoyJDBnCtCMmjJ72036k8Y4apUXkKXawvvOC6JoI+ BAB2YJ9wlb4UB4rVW7vXSgYrRpXZR/6FL06Op/1lBdyH3o7OaTbgeTULwCf4XeEB/RBb h25LkagEdZ+v771ak1nFchNRXrapRu2SxJhMspSEQRRXnEWebMa06YO1BytFbaKeHTdW Dku0STlTA+v/8wJ4TnuIpL4eS5bpIwpZpy0QA6yXZElY0h/2eeEuV3Q9foDmcRL5wtGx 8TyyA0EtAuakqxfQNPl1UmPNCtSEoLj6uopn4yUEh7QuRa5GHdUJ306obG8uEj+PMAOl 52Dw== 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=eU59rxENwIUXfP/hkexiPegOdSFviH50J3peVYVdfxA=; b=ryHS507gA1j7beeoxnZEgoxHMuOEPpCY57pkzEq9nrM8EMpRxF7kds04iY7XQtOXm0 Hhe0io4bOfX8Aq5jMS5dPxXZcH0kXq7/fNUwB2fkoSD5bd8bC1PXatjiNhEs2Hajz1zi 94y7jTpEAnNweEsKvdB/KJNppfPCBjz1j21YcrOoVLdgIi8rHYSS4sAZtBbhkB9F4M3N UTEiFa7Pv4yWhgjOAY4UKQu4pLOqeAMCy+g5g+n8cRQBhyZcl/laHym4ITKONCDsBw/l 4DsiCtyimk8/vOS2JEDHYCTwmMknYlTIFoQ1GC58+hq/1/YQqXQYmmsxHx9/KM5x4mXp s/Vg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=rMquAHeH; 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 jg13si4938828ejc.669.2021.02.11.08.13.33; Thu, 11 Feb 2021 08:14:15 -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=rMquAHeH; 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 S231861AbhBKQM4 (ORCPT + 99 others); Thu, 11 Feb 2021 11:12:56 -0500 Received: from mail.kernel.org ([198.145.29.99]:53526 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230317AbhBKPWj (ORCPT ); Thu, 11 Feb 2021 10:22:39 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id A300A64F3A; Thu, 11 Feb 2021 15:07:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1613056046; bh=G25eVsCG0FfJD+6TQYx5u0/1KEGw50qSzxQT6J01+js=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rMquAHeHjtAlOVJi1qj8ACMM5hw2A5YWhU73UNOHrGs79S+D3vi+/mgc+kP406dV3 wSOAD377ixPY91bSgBrAd1vV06OOutdHpXRxt6H7clEKAmIXGeqAVXSygW83c7y3vs bI4XAQxidMapUWKBAkBj38DMMecydPuC1NQKsiSU= 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 4.19 07/24] regulator: core: avoid regulator_resolve_supply() race condition Date: Thu, 11 Feb 2021 16:02:41 +0100 Message-Id: <20210211150148.069380965@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210211150147.743660073@linuxfoundation.org> References: <20210211150147.743660073@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 8a6ca06d9c160..fa8f5fc04d8fd 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -1567,23 +1567,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 resovle? */ 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; @@ -1591,15 +1602,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); } @@ -1613,7 +1627,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; } } @@ -1621,13 +1636,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; } /* Cascade always-on state to supply */ @@ -1636,11 +1651,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