[PATCH v3 0/4] gcov: use -fprofile-update=atomic globally to fix concurrent access crashes on GCOV-enabled kernels

[PATCH v3 0/4] gcov: use -fprofile-update=atomic globally to fix concurrent access crashes on GCOV-enabled kernels

[Konstantin Khorenko]

This series adds -fprofile-update=atomic to global CFLAGS_GCOV and
includes preparatory patches that fix build failures exposed by the new
flag.

Background
----------

This work combines and supersedes two previously separate series:

1. Build fix for CONFIG_GCOV_PROFILE_ALL=y - skb_ext_total_length()
   BUILD_BUG_ON failure:
   https://lore.kernel.org/lkml/20260331165125.959833-1-khorenko@virtuozzo.com/T/#t

2. Runtime crash fix for zlib inflate_fast() - GCOV counter merging
   with loop induction variables caused out-of-bounds writes on SMP:
   https://lore.kernel.org/lkml/20260330143256.306326-1-khorenko@virtuozzo.com/T/#t

The original zlib fix added -fprofile-update=atomic only to zlib
Makefiles. During review, it was suggested to apply the flag globally
instead, as it not only fixes the zlib crash but makes GCOV coverage
data more consistent overall. The GCC bug report for the underlying
compiler issue is at (and they also said just to use -fprofile-update=atomic):
   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124749

Adding -fprofile-update=atomic to global CFLAGS_GCOV exposed two
additional build failures that are addressed by preparatory patches
in this series.

Series overview
---------------

Patch 1/4: net: fix skb_ext_total_length() BUILD_BUG_ON
  Pre-existing build failure with CONFIG_GCOV_PROFILE_ALL=y. GCOV
  counters prevent GCC from constant-folding the skb_ext_total_length()
  loop. Fixed by adding __no_profile to the function and removing the
  now-unnecessary CONFIG_KCOV_INSTRUMENT_ALL preprocessor guard.
  (This is v2 of the previously posted standalone patch.)

Patch 2/4: net: add __no_profile to skb_extensions_init()
  With -fprofile-update=atomic, __no_profile on skb_ext_total_length()
  alone is insufficient - after __always_inline expansion the code
  resides in the caller's body which still has GCOV instrumentation.
  Mark the caller with __no_profile as well.

Patch 3/4: iommu/generic_pt: disable GCOV for iommu_amdv1.o
  FIELD_PREP() compile-time checks fail because the entire call chain
  is __always_inline functions generated by PT_MAKE_LEVELS() macro,
  and GCC's .constprop cloning creates new profiled function bodies
  that bypass __no_profile. Disable GCOV for this file.

Patch 4/4: gcov: use atomic counter updates to fix concurrent crashes
  The main fix. Add -fprofile-update=atomic to CFLAGS_GCOV in the
  top-level Makefile. This tells GCC to use atomic instructions for
  GCOV counter updates, preventing the compiler from merging counters
  with loop induction variables. This fixes observed crashes in zlib's
  inflate_fast() during concurrent IPComp decompression and makes GCOV
  data reliable across the entire kernel on SMP systems.

The crash that motivated this work
-----------------------------------

Observed during LTP IPComp stress testing on a GCOV-enabled kernel:

  BUG: unable to handle page fault for address: ffffd0a3c0902ffa
  RIP: inflate_fast+1431
  Call Trace:
   zlib_inflate
   __deflate_decompress
   crypto_comp_decompress
   ipcomp_decompress [xfrm_ipcomp]
   ipcomp_input [xfrm_ipcomp]
   xfrm_input

GCC merged a global GCOV counter with the loop induction variable.
Another CPU modified the counter between loads, causing a write 3.4 MB
past a 65 KB buffer. -fprofile-update=atomic forces atomic counter
updates and prevents this merging.

Testing
-------

- Build-tested with CONFIG_GCOV_PROFILE_ALL=y using GCC 11.4.1 and
  GCC 16.0.1 20260327 (experimental). Both fail without the series,
  both succeed with the full series applied.
- Assembly-verified that -fprofile-update=atomic prevents counter-IV
  merging in inflate_fast() on both compiler versions.

Konstantin Khorenko (4):
  net: fix skb_ext_total_length() BUILD_BUG_ON with CONFIG_GCOV_PROFILE_ALL
  net: add __no_profile to skb_extensions_init() for GCOV compatibility
  iommu/generic_pt: disable GCOV for iommu_amdv1.o
  gcov: use atomic counter updates to fix concurrent access crashes

 Makefile                              | 2 +-
 drivers/iommu/generic_pt/fmt/Makefile | 2 ++
 net/core/skbuff.c                     | 5 ++---
 3 files changed, 5 insertions(+), 4 deletions(-)

-- 
2.43.5

[PATCH v3 1/4] net: fix skb_ext_total_length() BUILD_BUG_ON with CONFIG_GCOV_PROFILE_ALL

[Konstantin Khorenko]

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>
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
 
 	skbuff_ext_cache = kmem_cache_create("skbuff_ext_cache",
 					     SKB_EXT_ALIGN_VALUE * skb_ext_total_length(),
-- 
2.43.5

[PATCH v3 2/4] net: add __no_profile to skb_extensions_init() for GCOV compatibility

[Konstantin Khorenko]

With -fprofile-update=atomic in global CFLAGS_GCOV, GCC still cannot
constant-fold the skb_ext_total_length() loop when it is inlined into a
profiled caller.  The existing __no_profile on skb_ext_total_length()
itself is insufficient because after __always_inline expansion the code
resides in the caller's body, which still carries GCOV instrumentation.

Mark skb_extensions_init() with __no_profile so the BUILD_BUG_ON checks
can be evaluated at compile time.

Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
---
 net/core/skbuff.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 47c7f0ab6e84..99704d6832e2 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -5156,7 +5156,7 @@ static __always_inline __no_profile unsigned int skb_ext_total_length(void)
 	return l;
 }
 
-static void skb_extensions_init(void)
+static void __no_profile skb_extensions_init(void)
 {
 	BUILD_BUG_ON(SKB_EXT_NUM > 8);
 	BUILD_BUG_ON(skb_ext_total_length() > 255);
-- 
2.43.5

[PATCH v3 3/4] iommu/generic_pt: disable GCOV for iommu_amdv1.o

[Konstantin Khorenko]

With -fprofile-update=atomic in global CFLAGS_GCOV, GCC cannot
constant-fold FIELD_PREP() expressions inside deeply inlined page table
walker functions.  GCC creates .constprop clones of the inline level
functions, which get their own GCOV instrumentation that prevents
constant evaluation of compile-time checks.

__no_profile cannot be used here because the entire call chain is
__always_inline functions generated by PT_MAKE_LEVELS() macro, and GCC's
constprop cloning creates new profiled function bodies that bypass the
attribute.

Disable GCOV for iommu_amdv1.o to allow BUILD_BUG_ON / FIELD_PREP
compile-time checks to succeed.

Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
---
 drivers/iommu/generic_pt/fmt/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/iommu/generic_pt/fmt/Makefile b/drivers/iommu/generic_pt/fmt/Makefile
index 976b49ec97dc..0305f7fb9e35 100644
--- a/drivers/iommu/generic_pt/fmt/Makefile
+++ b/drivers/iommu/generic_pt/fmt/Makefile
@@ -1,5 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 
+GCOV_PROFILE_iommu_amdv1.o := n
+
 iommu_pt_fmt-$(CONFIG_IOMMU_PT_AMDV1) += amdv1
 iommu_pt_fmt-$(CONFIG_IOMMUFD_TEST) += mock
 
-- 
2.43.5

[PATCH v3 4/4] gcov: use atomic counter updates to fix concurrent access crashes

[Konstantin Khorenko]

GCC's GCOV instrumentation can merge global branch counters with loop
induction variables as an optimization.  In inflate_fast(), the inner
copy loops get transformed so that the GCOV counter value is loaded
multiple times to compute the loop base address, start index, and end
bound.  Since GCOV counters are global (not per-CPU), concurrent
execution on different CPUs causes the counter to change between loads,
producing inconsistent values and out-of-bounds memory writes.

The crash manifests during IPComp (IP Payload Compression) processing
when inflate_fast() runs concurrently on multiple CPUs:

  BUG: unable to handle page fault for address: ffffd0a3c0902ffa
  RIP: inflate_fast+1431
  Call Trace:
   zlib_inflate
   __deflate_decompress
   crypto_comp_decompress
   ipcomp_decompress [xfrm_ipcomp]
   ipcomp_input [xfrm_ipcomp]
   xfrm_input

At the crash point, the compiler generated three loads from the same
global GCOV counter (__gcov0.inflate_fast+216) to compute base, start,
and end for an indexed loop.  Another CPU modified the counter between
loads, making the values inconsistent — the write went 3.4 MB past a
65 KB buffer.

Add -fprofile-update=atomic to CFLAGS_GCOV at the global level in the
top-level Makefile.  This tells GCC that GCOV counters may be
concurrently accessed, causing counter updates to use atomic
instructions (lock addq) instead of plain load/store.  This prevents
the compiler from merging counters with loop induction variables.

Applying this globally rather than per-subsystem not only addresses the
observed crash in zlib but makes GCOV coverage data more consistent
overall, preventing similar issues in any kernel code path that may
execute concurrently.

Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 6b1d9fb1a6b4..a55ad668d6ba 100644
--- a/Makefile
+++ b/Makefile
@@ -806,7 +806,7 @@ all: vmlinux
 
 CFLAGS_GCOV	:= -fprofile-arcs -ftest-coverage
 ifdef CONFIG_CC_IS_GCC
-CFLAGS_GCOV	+= -fno-tree-loop-im
+CFLAGS_GCOV	+= -fno-tree-loop-im -fprofile-update=atomic
 endif
 export CFLAGS_GCOV
 
-- 
2.43.5

Re: [PATCH v3 4/4] gcov: use atomic counter updates to fix concurrent access crashes

[Peter Oberparleiter]

On 01.04.2026 16:20, Konstantin Khorenko wrote:
> GCC's GCOV instrumentation can merge global branch counters with loop
> induction variables as an optimization.  In inflate_fast(), the inner
> copy loops get transformed so that the GCOV counter value is loaded
> multiple times to compute the loop base address, start index, and end
> bound.  Since GCOV counters are global (not per-CPU), concurrent
> execution on different CPUs causes the counter to change between loads,
> producing inconsistent values and out-of-bounds memory writes.
> 
> The crash manifests during IPComp (IP Payload Compression) processing
> when inflate_fast() runs concurrently on multiple CPUs:
> 
>   BUG: unable to handle page fault for address: ffffd0a3c0902ffa
>   RIP: inflate_fast+1431
>   Call Trace:
>    zlib_inflate
>    __deflate_decompress
>    crypto_comp_decompress
>    ipcomp_decompress [xfrm_ipcomp]
>    ipcomp_input [xfrm_ipcomp]
>    xfrm_input
> 
> At the crash point, the compiler generated three loads from the same
> global GCOV counter (__gcov0.inflate_fast+216) to compute base, start,
> and end for an indexed loop.  Another CPU modified the counter between
> loads, making the values inconsistent — the write went 3.4 MB past a
> 65 KB buffer.
> 
> Add -fprofile-update=atomic to CFLAGS_GCOV at the global level in the
> top-level Makefile.  This tells GCC that GCOV counters may be
> concurrently accessed, causing counter updates to use atomic
> instructions (lock addq) instead of plain load/store.  This prevents
> the compiler from merging counters with loop induction variables.
> 
> Applying this globally rather than per-subsystem not only addresses the
> observed crash in zlib but makes GCOV coverage data more consistent
> overall, preventing similar issues in any kernel code path that may
> execute concurrently.
> 
> Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>

Thanks, this looks good to me!

Successfully tested this series on s390 (except for patch 3 which
depends on x86) using GCC 15.2.0, GCC 10.1.0, and current Clang from git
(20260401).

Tested-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>

-- 
Peter Oberparleiter
Linux on IBM Z Development - IBM Germany R&D

Re: [PATCH v3 0/4] gcov: use -fprofile-update=atomic globally to fix concurrent access crashes on GCOV-enabled kernels

[Jakub Kicinski]

On Wed,  1 Apr 2026 17:20:16 +0300 Konstantin Khorenko wrote:
> 1. Build fix for CONFIG_GCOV_PROFILE_ALL=y - skb_ext_total_length()
>    BUILD_BUG_ON failure:
>    https://lore.kernel.org/lkml/20260331165125.959833-1-khorenko@virtuozzo.com/T/#t
> 
> 2. Runtime crash fix for zlib inflate_fast() - GCOV counter merging
>    with loop induction variables caused out-of-bounds writes on SMP:
>    https://lore.kernel.org/lkml/20260330143256.306326-1-khorenko@virtuozzo.com/T/#t

Why are you merging these? The should go via different subsystems.
How do you expect this series to be applied?
-- 
pw-bot: cr

Re: [PATCH v3 0/4] gcov: use -fprofile-update=atomic globally to fix concurrent access crashes on GCOV-enabled kernels

[Konstantin Khorenko]

On 4/2/26 03:46, Jakub Kicinski wrote:
> On Wed,  1 Apr 2026 17:20:16 +0300 Konstantin Khorenko wrote:
>> 1. Build fix for CONFIG_GCOV_PROFILE_ALL=y - skb_ext_total_length()
>>     BUILD_BUG_ON failure:
>>     https://lore.kernel.org/lkml/20260331165125.959833-1-khorenko@virtuozzo.com/T/#t
>>
>> 2. Runtime crash fix for zlib inflate_fast() - GCOV counter merging
>>     with loop induction variables caused out-of-bounds writes on SMP:
>>     https://lore.kernel.org/lkml/20260330143256.306326-1-khorenko@virtuozzo.com/T/#t
> 
> Why are you merging these? The should go via different subsystems.
> How do you expect this series to be applied?

You are definitely right, Jakub.

i will create 3 different threads and note explicitly that the last commit should be applied only 
after first 2 series are merged.

Will do right now!

--
Konstantin Khorenko