[Devel] [PATCH RHEL10 COMMIT] ms/gcov: use atomic counter updates to fix concurrent access crashes

Konstantin Khorenko khorenko at virtuozzo.com
Mon Jun 15 15:54:35 MSK 2026


The commit is pushed to "branch-rh10-6.12.0-211.16.1.12.x.vz10-ovz" and will appear at git at bitbucket.org:openvz/vzkernel.git
after rh10-6.12.0-211.16.1.12.1.vz10
------>
commit c3f6963973499de340a51a50b988b62d10fbbaf6
Author: Konstantin Khorenko <khorenko at virtuozzo.com>
Date:   Mon May 11 12:50:52 2026 +0200

    ms/gcov: use atomic counter updates to fix concurrent access crashes
    
    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.
    
    Link: https://lore.kernel.org/20260511105052.417187-2-khorenko@virtuozzo.com
    Signed-off-by: Konstantin Khorenko <khorenko at virtuozzo.com>
    Tested-by: Arnd Bergmann <arnd at arndb.de>
    Tested-by: Peter Oberparleiter <oberpar at linux.ibm.com>
    Reviewed-by: Peter Oberparleiter <oberpar at linux.ibm.com>
    Cc: Masahiro Yamada <masahiroy at kernel.org>
    Cc: Miguel Ojeda <ojeda at kernel.org>
    Cc: Mikhail Zaslonko <zaslonko at linux.ibm.com>
    Cc: Nathan Chancellor <nathan at kernel.org>
    Cc: Pavel Tikhomirov <ptikhomirov at virtuozzo.com>
    Cc: Thomas Weißschuh <linux at weissschuh.net>
    Cc: <stable at vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
    
    (cherry picked from akpm/mm tree commit 56cb9b7d96b28a1173a510ab25354b6599ad3a33)
    https://lore.kernel.org/lkml/20260511105052.417187-1-khorenko@virtuozzo.com/
    
    https://virtuozzo.atlassian.net/browse/VSTOR-127788
    https://virtuozzo.atlassian.net/browse/VSTOR-128012
    Feature: fix ms/gcov
    
    Signed-off-by: Konstantin Khorenko <khorenko at virtuozzo.com>
---
 Makefile | 27 +++++++++++++++++++++------
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/Makefile b/Makefile
index 89fdcffbe6cf..bbbf36bcb3d8 100644
--- a/Makefile
+++ b/Makefile
@@ -770,12 +770,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
@@ -1039,6 +1033,27 @@ ifdef CONFIG_CC_IS_GCC
 KBUILD_CFLAGS   += -fconserve-stack
 endif
 
+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 \
+	-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
+
 # change __FILE__ to the relative path from the srctree
 KBUILD_CPPFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=)
 


More information about the Devel mailing list