Re: [PATCH 1/2] net: fix skb_ext_total_length() BUILD_BUG_ON with CONFIG_GCOV_PROFILE_ALL

[Paolo Abeni <pabeni@redhat.com>]

On 4/2/26 4:05 PM, Konstantin Khorenko wrote:
> When CONFIG_GCOV_PROFILE_ALL=y is enabled, the kernel fails to build:
> 
>   In file included from <command-line>:
>   In function 'skb_extensions_init',
>       inlined from 'skb_init' at net/core/skbuff.c:5214:2:
>   ././include/linux/compiler_types.h:706:45: error: call to
>     '__compiletime_assert_1490' declared with attribute error:
>     BUILD_BUG_ON failed: skb_ext_total_length() > 255
> 
> CONFIG_GCOV_PROFILE_ALL adds -fprofile-arcs -ftest-coverage
> -fno-tree-loop-im to CFLAGS globally. GCC inserts branch profiling
> counters into the skb_ext_total_length() loop and, combined with
> -fno-tree-loop-im (which disables loop invariant motion), cannot
> constant-fold the result.
> BUILD_BUG_ON requires a compile-time constant and fails.
> 
> The issue manifests in kernels with 5+ SKB extension types enabled
> (e.g., after addition of SKB_EXT_CAN, SKB_EXT_PSP). With 4 extensions
> GCC can still unroll and fold the loop despite GCOV instrumentation;
> with 5+ it gives up.
> 
> Mark skb_ext_total_length() with __no_profile to prevent GCOV from
> inserting counters into this function. Without counters the loop is
> "clean" and GCC can constant-fold it even with -fno-tree-loop-im active.
> This allows BUILD_BUG_ON to work correctly while keeping GCOV profiling
> for the rest of the kernel.
> 
> This also removes the CONFIG_KCOV_INSTRUMENT_ALL preprocessor guard
> introduced by d6e5794b06c0, as __no_profile handles both GCOV and KCOV
> instrumentation at the root cause level rather than just disabling the
> check.
> 
> Fixes: 5d21d0a65b57 ("net: generalize calculation of skb extensions length")
> Fixes: d6e5794b06c0 ("net: avoid build bug in skb extension length calculation")
> 
> Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>

No empty lines in the tags area.

Also given the commit description, isn't the introduction of the 5th skb
extension a better fixes tag?

> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
>  net/core/skbuff.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 0e217041958a..47c7f0ab6e84 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -5145,7 +5145,7 @@ static const u8 skb_ext_type_len[] = {
>  #endif
>  };
>  
> -static __always_inline unsigned int skb_ext_total_length(void)
> +static __always_inline __no_profile unsigned int skb_ext_total_length(void)
>  {
>  	unsigned int l = SKB_EXT_CHUNKSIZEOF(struct skb_ext);
>  	int i;
> @@ -5159,9 +5159,7 @@ static __always_inline unsigned int skb_ext_total_length(void)
>  static void skb_extensions_init(void)
>  {
>  	BUILD_BUG_ON(SKB_EXT_NUM > 8);
> -#if !IS_ENABLED(CONFIG_KCOV_INSTRUMENT_ALL)
>  	BUILD_BUG_ON(skb_ext_total_length() > 255);
> -#endif

Sashiko notes that there could be still build breakage:

https://sashiko.dev/#/patchset/20260402140558.1437002-1-khorenko%40virtuozzo.com

Could you please double check the above?

I think a 'noinline' in skb_extensions_init() would address any
complains on patch 2/2

/P

>  
>  	skbuff_ext_cache = kmem_cache_create("skbuff_ext_cache",
>  					     SKB_EXT_ALIGN_VALUE * skb_ext_total_length(),