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

[Konstantin Khorenko]

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 21dbc85df5529997857708924e8d0b694ff29c43
Author: Konstantin Khorenko <khorenko at virtuozzo.com>
Date:   Wed Apr 1 15:48:09 2026 +0300

    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. On architectures where the target supports
    atomic profile updates (x86_64, arm64, ...) GCC emits atomic
    instructions (e.g. lock addq) for GCOV counter updates instead of plain
    load/store, which prevents the compiler from merging counters with loop
    induction variables and fixes the observed concurrent-access crash.
    
    On architectures that do not support atomic profile updates (m68k and
    other small/UP targets) GCC silently falls back to the non-atomic
    'single' mode, so behaviour there is no worse than before this patch.
    
    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 at virtuozzo.com>
    Tested-by: Peter Oberparleiter <oberpar at linux.ibm.com>
    Reviewed-by: Peter Oberparleiter <oberpar at linux.ibm.com>
    
    Not committed to the ms yet.
    https://lore.kernel.org/lkml/20260422125112.3583649-1-khorenko@virtuozzo.com/T/#t
    https://virtuozzo.atlassian.net/browse/VSTOR-127788
    https://virtuozzo.atlassian.net/browse/VSTOR-128012
    
    Feature: fix ms/gcov
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index e23ce694b8f9e..11cf2b64e552d 100644
--- a/Makefile
+++ b/Makefile
@@ -766,7 +766,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=prefer-atomic
 endif
 export CFLAGS_GCOV