[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3f42dee6-a6e2-1b35-674f-309aae042ae7@gmail.com>
Date: Wed, 22 Nov 2023 16:15:49 +0000
From: Edward Cree <ecree.xilinx@...il.com>
To: kernel test robot <lkp@...el.com>
Cc: llvm@...ts.linux.dev, oe-kbuild-all@...ts.linux.dev,
linux-kernel@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
Andy Moreton <andy.moreton@....com>,
Simon Horman <simon.horman@...igine.com>
Subject: Re: drivers/net/ethernet/sfc/selftest.c:48:16: warning: field ip
within 'struct efx_loopback_payload::(anonymous at
drivers/net/ethernet/sfc/selftest.c:46:2)' is less aligned than 'struct
iphdr' and is usually due to 'struct efx_loopback_payload::(anonymous a...
On 21/11/2023 21:25, kernel test robot wrote:
> Hi Edward,
>
> FYI, the error/warning still remains.
As I've argued previously, this is a false positive / compiler bug,
and there is no way to resolve it without making the code strictly
worse.
This:
>>> drivers/net/ethernet/sfc/selftest.c:48:16: warning: field ip within 'struct efx_loopback_payload::(anonymous at drivers/net/ethernet/sfc/selftest.c:46:2)' is less aligned than 'struct iphdr' and is usually due to 'struct efx_loopback_payload::(anonymous at drivers/net/ethernet/sfc/selftest.c:46:2)' being packed, which can lead to unaligned accesses [-Wunaligned-access]
is complaining about alignment within an anonymous struct, which
only ever appears embedded within a larger struct in a way which
maintains the correct alignment.
#ifdef RANT
Indeed, the only way we even *could* create an unaligned access
out of this code would be via a declaration like
typeof(*(((struct efx_loopback_payload *)0)->packet)) bad;
because *the struct is anonymous*. And if that happened, the
bad declaration would be the place to warn, both because it's
incredibly ugly and because it's the place that's actually
wrong. The struct definition itself is entirely *fine*.
The compiler should be able to detect that, and if it's not smart
enough to do so then it shouldn't be trying to warn in the first
place. Quoth Linus[1]:
"And if the compiler isn't good enough to do it, then the compiler
shouldn't be warning about something that it hasn't got a clue about."
The anonymous struct has to be there so that we can placate the
memcpy hardening, and it has to contain a struct iphdr at a
4n+2 offset because that's what shape the on-the-wire packet
*is*. To avoid the warning we would need to lose __packed and
memcpy all of the members in and out of the buffer individually
to explicitly-calculated offsets, which is worse code.
#endif
Either fix the compiler to not warn, or fix your automation to
ignore this instance of the warning.
-ed
[1]: https://yarchive.net/comp/linux/gcc.html#13
Powered by blists - more mailing lists