[Devel] [PATCH RHEL10 COMMIT] ms/net: fix skb_ext_total_length() BUILD_BUG_ON with CONFIG_GCOV_PROFILE_ALL

Konstantin Khorenko khorenko at virtuozzo.com
Wed Apr 22 17:23:54 MSK 2026


The commit is pushed to "branch-rh10-6.12.0-55.52.1.5.x.vz10-ovz" and will appear at git at bitbucket.org:openvz/vzkernel.git
after rh10-6.12.0-55.52.1.5.21.vz10
------>
commit 6fb9ac7643a24f428b5415ac8e0baf0c4ab5bbbd
Author: Konstantin Khorenko <khorenko at virtuozzo.com>
Date:   Fri Apr 10 19:21:49 2026 +0300

    ms/net: fix skb_ext_total_length() BUILD_BUG_ON with CONFIG_GCOV_PROFILE_ALL
    
    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. That guard was added as a precaution because
    KCOV instrumentation was also suspected of inhibiting constant folding.
    However, KCOV uses -fsanitize-coverage=trace-pc, which inserts
    lightweight trace callbacks that do not interfere with GCC's constant
    folding or loop optimization passes. Only GCOV's -fprofile-arcs combined
    with -fno-tree-loop-im actually prevents the compiler from evaluating
    the loop at compile time. The guard is therefore unnecessary and can be
    safely removed.
    
    Fixes: 96ea3a1e2d31 ("can: add CAN skb extension infrastructure")
    Signed-off-by: Konstantin Khorenko <khorenko at virtuozzo.com>
    Reviewed-by: Thomas Weissschuh <linux at weissschuh.net>
    Link: https://patch.msgid.link/20260410162150.3105738-2-khorenko@virtuozzo.com
    Signed-off-by: Jakub Kicinski <kuba at kernel.org>
    
    https://virtuozzo.atlassian.net/browse/VSTOR-127788
    https://virtuozzo.atlassian.net/browse/VSTOR-128012
    (cherry picked from linux-next commit c0b4382c86e3d92f79b71c9ed55654db520d7b36)
    Signed-off-by: Konstantin Khorenko <khorenko at virtuozzo.com>
    
    Feature: fix ms/gcov
---
 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 f13da68078e0c..d05be5d81d3b4 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -5050,7 +5050,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;
@@ -5064,9 +5064,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
 
 	skbuff_ext_cache = kmem_cache_create("skbuff_ext_cache",
 					     SKB_EXT_ALIGN_VALUE * skb_ext_total_length(),


More information about the Devel mailing list