The quilt patch titled Subject: gcov: use atomic counter updates to fix concurrent access crashes has been removed from the -mm tree. Its filename was gcov-use-atomic-counter-updates-to-fix-concurrent-access-crashes.patch This patch was dropped because an updated version will be issued ------------------------------------------------------ From: Konstantin Khorenko Subject: gcov: use atomic counter updates to fix concurrent access crashes Date: Wed, 22 Apr 2026 15:51:12 +0300 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. Link: https://lore.kernel.org/20260422125112.3583649-2-khorenko@virtuozzo.com Signed-off-by: Konstantin Khorenko Tested-by: Peter Oberparleiter Reviewed-by: Peter Oberparleiter Cc: Arnd Bergmann Cc: Masahiro Yamada Cc: Miguel Ojeda Cc: Mikhail Zaslonko Cc: Nathan Chancellor Cc: Pavel Tikhomirov Cc: Thomas Weißschuh Cc: Signed-off-by: Andrew Morton --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/Makefile~gcov-use-atomic-counter-updates-to-fix-concurrent-access-crashes +++ a/Makefile @@ -826,7 +826,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 _ Patches currently in -mm which might be from khorenko@virtuozzo.com are