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

[Peter Oberparleiter <oberpar@linux.ibm.com>]

On 11.05.2026 12:50, 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=prefer-atomic to CFLAGS_GCOV at the global level in
> the top-level Makefile, guarded by a try-run compile test.  The test
> compiles a minimal program with and without -fprofile-update=prefer-atomic
> using the full KBUILD_CFLAGS, then compares undefined symbols in the
> resulting object files.  If prefer-atomic introduces new undefined
> references (such as __atomic_fetch_add_8 on i386 or
> __aarch64_ldadd8_relax on arm64 with outline-atomics), the flag is not
> added -- the kernel does not link against libatomic.
> 
> On architectures where GCC inlines 64-bit atomic counter updates
> (x86_64, s390, ...) the test passes and the flag is enabled, preventing
> the compiler from merging counters with loop induction variables and
> fixing the observed concurrent-access crash.
> 
> On architectures where the flag would introduce libatomic dependencies,
> it is silently omitted and behaviour is no worse than before this patch.
> 
> Move the CFLAGS_GCOV block from its original position (before the arch
> Makefile include) to after the core KBUILD_CFLAGS assignments but before
> the scripts/Makefile.gcc-plugins include.
> This placement ensures the try-run test sees arch-specific flags
> (-m32, -march=, -mno-outline-atomics) while avoiding GCC plugin flags
> (-fplugin=) that would break the test on clean builds when plugin shared
> objects do not yet exist.
> 
> Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>

Thank you for providing this updated fix - I greatly appreciate you
working on this.

I tested this patch successfully on s390 with GCC 15.2 and GCC 16.1.

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

That said, I found some stylistic details where the patch could be
improved that I've described below for consideration/comments. But I
don't want to delay the fix any longer than necessary, therefore I'm
fine with this patch, even when not including my suggestions.

> ---
>  Makefile | 27 +++++++++++++++++++++------
>  1 file changed, 21 insertions(+), 6 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 9f88dcaae382..2b352ad22d06 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -824,12 +824,6 @@ endif # KBUILD_EXTMOD
>  # Defaults to vmlinux, but the arch makefile usually adds further targets
>  all: vmlinux
>  
> -CFLAGS_GCOV	:= -fprofile-arcs -ftest-coverage
> -ifdef CONFIG_CC_IS_GCC
> -CFLAGS_GCOV	+= -fno-tree-loop-im
> -endif
> -export CFLAGS_GCOV
> -
>  # The arch Makefiles can override CC_FLAGS_FTRACE. We may also append it later.
>  ifdef CONFIG_FUNCTION_TRACER
>    CC_FLAGS_FTRACE := -pg
> @@ -1147,6 +1141,27 @@ endif
>  # Ensure compilers do not transform certain loops into calls to wcslen()
>  KBUILD_CFLAGS += -fno-builtin-wcslen
>  
> +CFLAGS_GCOV	:= -fprofile-arcs -ftest-coverage
> +ifdef CONFIG_CC_IS_GCC
> +CFLAGS_GCOV	+= -fno-tree-loop-im
> +# Use atomic counter updates to avoid concurrent-access crashes in GCOV.
> +# Only enable if -fprofile-update=prefer-atomic does not introduce new
> +# undefined symbols (e.g. libatomic calls that the kernel cannot link).
> +CFLAGS_GCOV	+= $(call try-run,\
> +	echo 'long long x; void f(void){x++;}' | \
> +	$(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) -w -fprofile-arcs \
> +	-ftest-coverage -x c - -c -o "$$TMP.base" && \
> +	echo 'long long x; void f(void){x++;}' | \
> +	$(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) -w -fprofile-arcs \
> +	-ftest-coverage -fprofile-update=prefer-atomic \

Using $(CFLAGS_GCOV) instead of listing -fprofile-arcs -ftest-coverage
separately would reduce duplication, automatically account for potential
future changes in the list of flags used for GCOV profiling, as well as
cover any side-effects that the third flag -fno-tree-loop-im might
have/get in the future.

> +	-x c - -c -o "$$TMP" && \
> +	$(NM) "$$TMP.base" | grep ' U ' > "$$TMP.ubase" || true ; \
> +	$(NM) "$$TMP" | grep ' U ' > "$$TMP.utest" || true ; \
> +	cmp -s "$$TMP.ubase" "$$TMP.utest",\
> +	-fprofile-update=prefer-atomic)
> +endif
> +export CFLAGS_GCOV
> +

Not directly related with the functional aspects of this patch, but
since all GCOV-related Makefile portions are touched/moved this would be
a good opportunity to follow the pattern of other instrumentation
mechanisms like KCOV, KASAN, etc., that is:

- split out the CFLAGS_GCOV chunk above into a new scripts/Makefile.gcov
  file
- include this file depending on the value of CONFIG_GCOV_KERNEL via
  include-$(CONFIG_GCOV_KERNEL) += scripts/Makefile.gcov
  in the "additional Makefile" section that follows after this
  Makefile position


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