netdev - Re: [PATCH net-next v2 06/10] drivers/net/ethernet: handle one warning explicitly

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] [day] [month] [year] [list]

Message-ID: <3C4D967A-183C-4EA9-BA87-CE6731C24AAF@intel.com>
Date:   Thu, 17 Sep 2020 20:06:10 +0000
From:   "Rustad, Mark D" <mark.d.rustad@...el.com>
To:     Saeed Mahameed <saeed@...nel.org>
CC:     "Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>
Subject: Re: [PATCH net-next v2 06/10] drivers/net/ethernet: handle one
 warning explicitly

at 8:25 PM, Saeed Mahameed <saeed@...nel.org> wrote:

> I don't have any strong feeling against disabling compiler warnings,
> but maybe the right thing to do here is to initialize the gaps to the
> invalid value instead of pre-initializing the whole thing first and
> then setting up the valid values on the 2nd pass.
>
> I don't think there are too many gaps to fill, it is doable, so maybe
> add this as a comment to this driver maintainer so they could pickup
> the work from here.

The problem is that filling in the gaps creates a maintenance hazard. As  
another example, the kernel does exactly this kind of thing to initialize  
the system call table. Using the override in this way is the clearest,  
easiest to maintain way of expressing this.

Disabling the warning not only gets rid of the warning, but should also be  
seen as a "something special is happening here" flag in the code. With the  
warning disabled, there is a hazard of now missing the possible  
introduction of an override here, but I think that risk is less than the  
risk of failing to fill a gap when changes are made.

I completely support doing this in exactly this way.

--
Mark Rustad, Ethernet Products Group, Intel Corporation

Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)