netdev - Re: [PATCH net-netx] net: renesas: sh_eth: suppress initialized field overwritten 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] [day] [month] [year] [list]

Message-Id: <20200920.142828.1649305713979064139.davem@davemloft.net>
Date:   Sun, 20 Sep 2020 14:28:28 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     liujian56@...wei.com
Cc:     sergei.shtylyov@...il.com, kuba@...nel.org, netdev@...r.kernel.org,
        linux-renesas-soc@...r.kernel.org
Subject: Re: [PATCH net-netx] net: renesas: sh_eth: suppress initialized
 field overwritten warning

From: Liu Jian <liujian56@...wei.com>
Date: Sat, 19 Sep 2020 18:59:45 +0800

> Suppress a bunch of warnings of the form:
> 
> drivers/net/ethernet/renesas/sh_eth.c:100:13: warning: initialized field overwritten [-Woverride-init]
> 
> This is because after the sh_eth_offset_xxx array is initialized to SH_ETH_OFFSET_INVALID,
> some specific register_offsets are re-initialized. It wasn't a mistake.
> 
> Signed-off-by: Liu Jian <liujian56@...wei.com>

Even if I agreed with this approach to the fix, you can't just blindly
add a CFLAG option.  What if the compile doesn't understand or support
that option?

I leave it to the patch submitter to grep the Makefiles in the tree to
learn how to handle this situation properly, because that's how I
learned what the right thing to do since I wasn't sure.

But in the end I think just sticking a warning disable here and there
isn't the solution.  I think this driver should explicitly initialize
the array entries that are invalid on each and every chip.

No only does that get rid of the warnings cleanly, but it also more
clearly documents the available register set.  Currently you have to
walk each and every enumeration value in the sh_eth.h header and
see if the table has it or not, in order to figure out which registers
are _not_ present for a chip.

Thank you.