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;
Sender: collinsd=codeaurora.org@mg.codeaurora.org
DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 4F7ECC433CA
Subject: Re: [PATCH] regulator: core: avoid regulator_resolve_supply() race
 condition
To:     Mark Brown <broonie@kernel.org>
Cc:     Marek Szyprowski <m.szyprowski@samsung.com>,
        Liam Girdwood <lgirdwood@gmail.com>,
        Krzysztof Kozlowski <krzk@kernel.org>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
        'Linux Samsung SOC' <linux-samsung-soc@vger.kernel.org>
References: <1610068562-4410-1-git-send-email-collinsd@codeaurora.org>
 <CGME20210112213419eucas1p24231e4d0ac11c31184f2f8f3f20cbd9d@eucas1p2.samsung.com>
 <e512ee85-7fa6-e5fe-eb30-f088bb83cf23@samsung.com>
 <20210118204958.GS4455@sirena.org.uk>
 <5f37ae96-c5f9-6619-d88f-21c5e483ff8e@samsung.com>
 <20210121154418.GE4588@sirena.org.uk>
 <e7e4b633-21cb-54e6-f75c-fac28147396c@samsung.com>
From:   David Collins <collinsd@codeaurora.org>
Message-ID: <5d02de1f-a6f4-c564-6738-2ca46b5d5cc0@codeaurora.org>
Date:   Fri, 22 Jan 2021 17:54:56 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <e7e4b633-21cb-54e6-f75c-fac28147396c@samsung.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hello Mark,

On 1/21/21 12:30 PM, Marek Szyprowski wrote:
> Hi Mark,
> 
> On 21.01.2021 16:44, Mark Brown wrote:
>> On Thu, Jan 21, 2021 at 10:41:59AM +0100, Marek Szyprowski wrote:
>>> On 18.01.2021 21:49, Mark Brown wrote:
>>>> Does this help (completely untested):
>>> Sadly nope. I get same warning:
>> Try this instead:
>>
>> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
>> index 3ae5ccd9277d..31503776dbd7 100644
>> --- a/drivers/regulator/core.c
>> +++ b/drivers/regulator/core.c
>> @@ -1823,17 +1823,6 @@ static int regulator_resolve_supply(struct regulator_dev *rdev)
>>    	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);
>> @@ -1885,12 +1874,29 @@ static int regulator_resolve_supply(struct regulator_dev *rdev)
>>    		goto out;
>>    	}
>>    
>> +	/*
>> +	 * 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) {
>> +		regulator_unlock(rdev);
>> +		put_device(&r->dev);
>> +		return ret;
>> +	}
>> +
>>    	ret = set_supply(rdev, r);
>>    	if (ret < 0) {
>> +		regulator_unlock(rdev);
>>    		put_device(&r->dev);
>> -		goto out;
>> +		return ret;
>>    	}
>>    
>> +	regulator_unlock(rdev);
>> +
>>    	/*
>>    	 * In set_machine_constraints() we may have turned this regulator on
>>    	 * but we couldn't propagate to the supply if it hadn't been resolved
>> @@ -1901,12 +1907,11 @@ static int regulator_resolve_supply(struct regulator_dev *rdev)
>>    		if (ret < 0) {
>>    			_regulator_put(rdev->supply);
>>    			rdev->supply = NULL;
>> -			goto out;
>> +			goto out_rdev_lock;
> 
> drivers/regulator/core.c:1910:4: error: label ‘out_rdev_lock’ used but
> not defined
> 
>>    		}
>>    	}
>>    
>>    out:
>> -	regulator_unlock(rdev);
>>    	return ret;
>>    }
>>    
> 
> It looks that it finally fixes the locking issue, with the above goto
> removed completely to fix build. Feel free to add:
> 
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> 
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>

Thank you for making this fix.  I'm sorry that I missed the potential 
deadlock issue resulting from the regulator_enable() call inside 
regulator_resolve_supply() with rdev->mutex locked.  Your fix avoids 
deadlock while still ensuring that the there isn't a set supply race 
condition.

Take care,
David

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project