Messages in this thread | | | Date | Thu, 23 Nov 2023 11:05:01 +0800 | From | Yujie Liu <> | 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::(anonym |
| |
On Wed, Nov 22, 2023 at 04:15:49PM +0000, Edward Cree wrote: > 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.
Hi Edward,
Thanks a lot for the detailed explanation. We've configured the robot to ignore the "unaligned access" warning for this specific case.
Best Regards, Yujie
> -ed > > [1]: https://yarchive.net/comp/linux/gcc.html#13 >
| |