linux-kernel - Re: [PATCH] [v2] media: venus: core: Fix runtime PM imbalance in venus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 27 Jun 2020 00:01:55 +0300
From:   Stanimir Varbanov <stanimir.varbanov@...aro.org>
To:     dinghao.liu@....edu.cn
Cc:     kjlu@....edu, Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [v2] media: venus: core: Fix runtime PM imbalance in
 venus_probe

Hi,

On 6/26/20 3:54 AM, dinghao.liu@....edu.cn wrote:
> 
>> Hi Dinghao,
>>
>> On 6/24/20 9:30 AM, Dinghao Liu wrote:
>>> pm_runtime_get_sync() increments the runtime PM usage counter even
>>> when it returns an error code. Thus a pairing decrement is needed on
>>> the error handling path to keep the counter balanced. For other error
>>> paths after this call, things are the same.
>>>
>>> Signed-off-by: Dinghao Liu <dinghao.liu@....edu.cn>
>>> ---
>>>
>>> Changelog:
>>>
>>> v2: - Add pm_runtime_get_noresume() on failure of
>>>       pm_runtime_put_sync() to balance PM counter instead of
>>>       releasing everything here.

Could you reword this and add it to the patch description.

>>
>> You are adding pm_runtime_get_noresume in pm_runtime_put_sync error path
>> but the patch description is referring to pm_runtime_get_sync. I'm confused.
>>
> 
> When pm_runtime_put_sync failed, the control flow will jump to 
> err_dev_unregister, where has already been a pm_runtime_put_noidle. 
> If we don't add an extra pm_runtime_get_noresume here, we will 
> decrease PM usage counter twice.
> 
> Anyway, this may seem a little strange. Do you have a better
> strategy to reorder the labels?

No, it looks fine. With above addition to patch description:

Acked-by: Stanimir Varbanov <stanimir.varbanov@...aro.org>

> 
> Regards,
> Dinghao
> 
>>> ---
>>>  drivers/media/platform/qcom/venus/core.c | 5 ++++-
>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c
>>> index 203c6538044f..b0b932bf8c02 100644
>>> --- a/drivers/media/platform/qcom/venus/core.c
>>> +++ b/drivers/media/platform/qcom/venus/core.c
>>> @@ -287,8 +287,10 @@ static int venus_probe(struct platform_device *pdev)
>>>  		goto err_core_deinit;
>>>  
>>>  	ret = pm_runtime_put_sync(dev);
>>> -	if (ret)
>>> +	if (ret) {
>>> +		pm_runtime_get_noresume(dev);
>>>  		goto err_dev_unregister;
>>> +	}
>>>  
>>>  	return 0;
>>>  
>>> @@ -299,6 +301,7 @@ static int venus_probe(struct platform_device *pdev)
>>>  err_venus_shutdown:
>>>  	venus_shutdown(core);
>>>  err_runtime_disable:
>>> +	pm_runtime_put_noidle(dev);
>>>  	pm_runtime_set_suspended(dev);
>>>  	pm_runtime_disable(dev);
>>>  	hfi_destroy(core);
>>>
>>
>> -- 
>> regards,
>> Stan

-- 
regards,
Stan