tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: 3b8a9b2e6809d281890dd0a1102dc14d2cd11caf
commit: 5d21d0a65b573507bae774708199328b38dedfe6 net: generalize calculation of skb extensions length
date: 4 months ago
config: um-randconfig-r025-20230617 (https://download.01.org/0day-ci/archive/20231217/[email protected]/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231217/[email protected]/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
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
397 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
include/linux/compiler_types.h:378:25: note: in definition of macro '__compiletime_assert'
378 | prefix ## suffix(); \
| ^~~~~~
include/linux/compiler_types.h:397:9: note: in expansion of macro '_compiletime_assert'
397 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:50:9: note: in expansion of macro 'BUILD_BUG_ON_MSG'
50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
| ^~~~~~~~~~~~~~~~
net/core/skbuff.c:4800:9: note: in expansion of macro 'BUILD_BUG_ON'
4800 | BUILD_BUG_ON(skb_ext_total_length() > 255);
| ^~~~~~~~~~~~
vim +/__compiletime_assert_810 +397 include/linux/compiler_types.h
eb5c2d4b45e3d2d Will Deacon 2020-07-21 383
eb5c2d4b45e3d2d Will Deacon 2020-07-21 384 #define _compiletime_assert(condition, msg, prefix, suffix) \
eb5c2d4b45e3d2d Will Deacon 2020-07-21 385 __compiletime_assert(condition, msg, prefix, suffix)
eb5c2d4b45e3d2d Will Deacon 2020-07-21 386
eb5c2d4b45e3d2d Will Deacon 2020-07-21 387 /**
eb5c2d4b45e3d2d Will Deacon 2020-07-21 388 * compiletime_assert - break build and emit msg if condition is false
eb5c2d4b45e3d2d Will Deacon 2020-07-21 389 * @condition: a compile-time constant condition to check
eb5c2d4b45e3d2d Will Deacon 2020-07-21 390 * @msg: a message to emit if condition is false
eb5c2d4b45e3d2d Will Deacon 2020-07-21 391 *
eb5c2d4b45e3d2d Will Deacon 2020-07-21 392 * In tradition of POSIX assert, this macro will break the build if the
eb5c2d4b45e3d2d Will Deacon 2020-07-21 393 * supplied condition is *false*, emitting the supplied error message if the
eb5c2d4b45e3d2d Will Deacon 2020-07-21 394 * compiler has support to do so.
eb5c2d4b45e3d2d Will Deacon 2020-07-21 395 */
eb5c2d4b45e3d2d Will Deacon 2020-07-21 396 #define compiletime_assert(condition, msg) \
eb5c2d4b45e3d2d Will Deacon 2020-07-21 @397 _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
eb5c2d4b45e3d2d Will Deacon 2020-07-21 398
:::::: The code at line 397 was first introduced by commit
:::::: eb5c2d4b45e3d2d5d052ea6b8f1463976b1020d5 compiler.h: Move compiletime_assert() macros into compiler_types.h
:::::: TO: Will Deacon <[email protected]>
:::::: CC: Will Deacon <[email protected]>
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
+Cc Arnd who was taking care of CFLAGS_GCOV in the past.
On 2023-12-17 19:39:34+0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: 3b8a9b2e6809d281890dd0a1102dc14d2cd11caf
> commit: 5d21d0a65b573507bae774708199328b38dedfe6 net: generalize calculation of skb extensions length
> date: 4 months ago
> config: um-randconfig-r025-20230617 (https://download.01.org/0day-ci/archive/20231217/[email protected]/config)
> compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231217/[email protected]/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <[email protected]>
> | Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
>
> 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
> 397 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> | ^
> include/linux/compiler_types.h:378:25: note: in definition of macro '__compiletime_assert'
> 378 | prefix ## suffix(); \
> | ^~~~~~
> include/linux/compiler_types.h:397:9: note: in expansion of macro '_compiletime_assert'
> 397 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> | ^~~~~~~~~~~~~~~~~~~
> include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
> 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> | ^~~~~~~~~~~~~~~~~~
> include/linux/build_bug.h:50:9: note: in expansion of macro 'BUILD_BUG_ON_MSG'
> 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
> | ^~~~~~~~~~~~~~~~
> net/core/skbuff.c:4800:9: note: in expansion of macro 'BUILD_BUG_ON'
> 4800 | BUILD_BUG_ON(skb_ext_total_length() > 255);
> | ^~~~~~~~~~~~
[..]
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...
Thomas
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/[email protected]/
>>
>> 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.
> [..]
>
> 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?
Arnd
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/[email protected]/
> >>
> >> 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.
On Mon, Dec 18, 2023, at 11:11, Thomas Weißschuh wrote:
> On 2023-12-18 10:12:03+0000, Arnd Bergmann wrote:
>> On Sun, Dec 17, 2023, at 17:13, Thomas Weißschuh wrote:
>>
>> 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.
Ah, I missed that.
I also see that I added -fno-tree-loop-im back in 2016 as a workaround
for gcc-4.9 and higher, but I don't know if it's still required
with modern compilers and I'm currently unable to do large scale
testing of this until maybe early January. My guess would be that it's
still needed.
If you want to fix it sooner and not revert your earlier patch,
I would suggest changing the BUILD_BUG_ON to only evaluate the
length argument if CONFIG_GCOV_PROFILE_ALL is disabled. It's not great
but if we ever exceed the limit for real it would still be caught
in normal defconfig and allmodconfig builds since they disable
the option.
Arnd