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, 4 Nov 2022 11:33:07 -0700
From:   Tony Nguyen <anthony.l.nguyen@...el.com>
To:     Jiri Slaby <jirislaby@...nel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        "Loktionov, Aleksandr" <aleksandr.loktionov@...el.com>,
        Jan Sokolowski <jan.sokolowski@...el.com>
CC:     <jesse.brandeburg@...el.com>, <linux-kernel@...r.kernel.org>,
        Martin Liska <mliska@...e.cz>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        <intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>
Subject: Re: [PATCH] i40e (gcc13): synchronize allocate/free functions return
 type & values

On 11/3/2022 5:03 AM, Jiri Slaby wrote:
> On 03. 11. 22, 4:41, Jakub Kicinski wrote:
>> On Mon, 31 Oct 2022 12:44:56 +0100 Jiri Slaby (SUSE) wrote:
>>> I.e. the type of their return value in the definition is int, while the
>>> declaration spell enum i40e_status. Synchronize the definitions to the
>>> latter.
>>>
>>> And make sure proper values are returned. I.e. I40E_SUCCESS and not 0,
>>> I40E_ERR_NO_MEMORY and not -ENOMEM.
>>
>> Let's go the opposite way, towards using standard errno.
> 
> This is propagated several layers up throughout the whole i40e driver. 
> It would be a mass change which I'd rather leave up to the driver 
> maintainers -- I don't even have the HW to test.

Hi Jakub,

As Jiri mentioned, this is propagated up throughout the driver. We could 
change this function to return int but all the callers would then need 
to convert these errors to i40e_status to propagate. This doesn't really 
gain much other than having this function return int. To adjust the 
entire call chain is going to take more work. As this is resolving a 
valid warning and returning what is currently expected, what are your 
thoughts on taking this now to resolve the issue and our i40e team will 
take the work on to convert the functions to use the standard errnos?

Thanks,
Tony

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ