[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bfe530f9-d3d4-4cdf-b92b-2fab95f44522@t-8ch.de>
Date: Mon, 18 Dec 2023 12:11:17 +0100
From: Thomas Weißschuh <linux@...ssschuh.net>
To: Arnd Bergmann <arnd@...db.de>
Cc: kernel test robot <lkp@...el.com>, oe-kbuild-all@...ts.linux.dev,
linux-kernel@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
Simon Horman <horms@...nel.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
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.
Powered by blists - more mailing lists