netdev - Re: [PATCH] i40e (gcc13): synchronize allocate/free functions return type & values

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:47:30 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Tony Nguyen <anthony.l.nguyen@...el.com>
Cc:     Jiri Slaby <jirislaby@...nel.org>,
        "Loktionov, Aleksandr" <aleksandr.loktionov@...el.com>,
        Jan Sokolowski <jan.sokolowski@...el.com>,
        <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 Fri, 4 Nov 2022 11:33:07 -0700 Tony Nguyen wrote:
> 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?

My thoughts on your OS abstraction layers should be pretty evident.
If anything I'd like to be more vigilant about less flagrant cases.

I don't think this is particularly difficult, let's patch it up
best we can without letting the "status" usage grow.