Received-SPF: pass (google.com: domain of linux-kernel+bounces-3417-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Mon, 18 Dec 2023 12:11:17 +0100
From: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= <linux@weissschuh.net>
To: Arnd Bergmann <arnd@arndb.de>
Cc: kernel test robot <lkp@intel.com>, oe-kbuild-all@lists.linux.dev, 
	linux-kernel@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>, 
	Simon Horman <horms@kernel.org>
Subject: Re: include/linux/compiler_types.h:397:45: error: call to
 '__compiletime_assert_810' declared with attribute error: BUILD_BUG_ON
 failed: skb_ext_total_length() > 255
Message-ID: <bfe530f9-d3d4-4cdf-b92b-2fab95f44522@t-8ch.de>
References: <202312171924.4FozI5FG-lkp@intel.com>
 <3fb66648-5581-4371-b15e-23e52e6469ba@t-8ch.de>
 <b091f9d3-14e9-4f2c-bf98-9a207cef412a@app.fastmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <b091f9d3-14e9-4f2c-bf98-9a207cef412a@app.fastmail.com>

On 2023-12-18 10:12:03+0000, Arnd Bergmann wrote:
> On Sun, Dec 17, 2023, at 17:13, Thomas Weißschuh wrote:
> > +Cc Arnd who was taking care of CFLAGS_GCOV in the past.
> >
> > On 2023-12-17 19:39:34+0800, kernel test robot wrote:
> >> | Closes: https://lore.kernel.org/oe-kbuild-all/202312171924.4FozI5FG-lkp@intel.com/
> >> 
> >> All errors (new ones prefixed by >>):
> >> 
> >>    In file included from <command-line>:
> >>    In function 'skb_extensions_init',
> >>        inlined from 'skb_init' at net/core/skbuff.c:4848:2:
> >> >> include/linux/compiler_types.h:397:45: error: call to '__compiletime_assert_810' declared with attribute error: BUILD_BUG_ON failed: skb_ext_total_length() > 255
> 
> I tried to count the actual number of bytes and got to a worst case of 200
> bytes (for 64-bit machines), but this may have been wrong. I can think of two
> possible things that may have caused the problem:
> 
> a) there is an actual overflow but gcc fails to realize it without GCOV
> b) the compile-time calculation goes wrong and is no longer a constant
>    value, so the assertion fails to evaluate
> 
> We can probably elinminate a) if you can show that raising the limit does
> not avoid the problem.

I raised the limit and the issue persists.

Also I replaced all entries in the array with a constant "0" and the
issue also persists.
So it can't be a).

Funnily when I keep the explicit array initializers and set all values
to "0" then the tripping point is from 4 to 5 array elements, the same
as with the current code.

With a plain array initialization the tripping point is from 2 to 3
elements.

> > [..]
> >
> > This seems to be a compiler bug/configuration issue.
> >
> > When I remove the entry for SKB_EXT_MCTP from skb_ext_type_len then the
> > error goes away. However this entry works the same as all other entries.
> >
> > Also dropping -fno-tree-loop-im *or* -fprofile-arcs from CFLAGS_GCOV
> > makes the code compile as-is.
> >
> > Or switching to a 64bit build...
> 
> The -fno-tree-loop-im option would likely stop the loop from getting
> unrolled, which is how the skb_ext_total_length() return code is no
> longer constant.
> 
> Does manually unrolling this loop avoid the problem?

That also works.

The offending commit was a change from a manually unrolled loop to the
current code.
This code is a few months old but somehow the issue was only found now.