linux-kernel - Re: [PATCH] accel/amdxdna: Use int instead of u32 to store error codes

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]

Message-ID: <6222cb69-fbb5-07b8-043c-cf0c25c9f3f0@amd.com>
Date: Wed, 27 Aug 2025 10:18:12 -0700
From: Lizhi Hou <lizhi.hou@....com>
To: Qianfeng Rong <rongqianfeng@...o.com>, Min Ma <min.ma@....com>, "Oded
 Gabbay" <ogabbay@...nel.org>, <dri-devel@...ts.freedesktop.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] accel/amdxdna: Use int instead of u32 to store error
 codes


On 8/26/25 19:15, Qianfeng Rong wrote:
>
> 在 2025/8/27 0:31, Lizhi Hou 写道:
>>
>> On 8/26/25 00:29, Qianfeng Rong wrote:
>>> Change the 'ret' variable from u32 to int to store -EINVAL, reducing
>>> potential risks such as incorrect results when comparing 'ret' with
>>> error codes.
>>
>> Sounds this fixes code issue. Could you add "Fixes" tag?
>>
>>
>
> The 'ret' variable stores negative error codes directly.  Storing
> error codes in u32 (an unsigned type) causes no runtime issues but is
> stylistically inconsistent and very ugly.
>
> Logical errors with 'ret' only occur when it is compared against negative
> error codes. For example:
>
> u32 ret = -EINVAL; // ret becomes an extremely large unsigned integer
>
> if (ret == -EINVAL) // This condition will never be true
>
> This patch reduces the likelihood of such issues occurring. Since it does
> not fix an existing bug, I believe there is no need to add a Fixes tag.

I agree with the change.

u32 ret = -EINVAL may lead to a gcc warning if -Wsign-conversion is 
enabled. That is why I suggested Fixes tag.

Lizhi

>
> Best regards,
> Qianfeng
>