linux-kernel - Re: [PATCH] remoteproc: silence an uninitialized variable warning

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 5 Apr 2019 12:38:19 +0530
From:   Mukesh Ojha <mojha@...eaurora.org>
To:     Dan Carpenter <dan.carpenter@...cle.com>
Cc:     Andy Gross <andy.gross@...aro.org>,
        David Brown <david.brown@...aro.org>,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] remoteproc: silence an uninitialized variable warning


On 4/4/2019 3:06 PM, Dan Carpenter wrote:
> On Thu, Apr 04, 2019 at 02:47:39PM +0530, Mukesh Ojha wrote:
>> On 4/4/2019 2:12 PM, Dan Carpenter wrote:
>>> Smatch complains that "ret" might be uninitialized.  I can see why it
>>> generates the warning, but I don't know if it's actually possible.
>>> Anyway initializing "ret" here is harmless.
>>>
>>> Signed-off-by: Dan Carpenter <dan.carpenter@...cle.com>
>>> ---
>>>    drivers/soc/qcom/mdt_loader.c | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
>>> index 1c488024c698..fc58d660692f 100644
>>> --- a/drivers/soc/qcom/mdt_loader.c
>>> +++ b/drivers/soc/qcom/mdt_loader.c
>>> @@ -188,7 +188,7 @@ static int __qcom_mdt_load(struct device *dev, const struct firmware *fw,
>>>    	if (reloc_base)
>>>    		*reloc_base = mem_reloc;
>>> -
>>> +	ret = 0;
>>
>> You are overriding the value here, better keep it at the start.
> I like how I wrote it.  It makes it clear that this is the success path.


But think about a case when this request_firmware_into_buf fails or the 
snippet above that can set the ret with error value

right.. is not that possible?..and ret = 0 stops propagating the error 
properly.

Thanks
Mukesh

>
> regards,
> dan carpenter
>