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

[Thomas Weißschuh]

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@xxxxxxxxx/
> >> 
> >> 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.