Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7;
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...
To:     kernel test robot <lkp@intel.com>
Cc:     llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
        linux-kernel@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>,
        Andy Moreton <andy.moreton@amd.com>,
        Simon Horman <simon.horman@corigine.com>
References: <202311220537.geMTr31W-lkp@intel.com>
From:   Edward Cree <ecree.xilinx@gmail.com>
Message-ID: <3f42dee6-a6e2-1b35-674f-309aae042ae7@gmail.com>
Date:   Wed, 22 Nov 2023 16:15:49 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <202311220537.geMTr31W-lkp@intel.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Precedence: bulk

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