[PATCH v2 0/1] gcov: use -fprofile-update=prefer-atomic to fix concurrent access crashes

[PATCH v2 0/1] gcov: use -fprofile-update=prefer-atomic to fix concurrent access crashes

[Konstantin Khorenko]

This patch adds -fprofile-update=prefer-atomic to global CFLAGS_GCOV in
the top-level Makefile to fix crashes caused by GCC merging GCOV
counters with loop induction variables in concurrent code paths.

Changes in v2
-------------

 - Use -fprofile-update=prefer-atomic instead of -fprofile-update=atomic
   to avoid a "target does not support atomic profile update, single
   mode is selected" warning emitted by GCC for every translation unit
   on architectures that lack atomic profile update support (reported
   by the kernel test robot on m68k-allmodconfig):

     https://lore.kernel.org/all/202604111946.Erd3tguU-lkp@intel.com/

   On architectures that do support atomic profile updates (x86_64,
   arm64, s390, ...) behaviour is unchanged: GCC still emits atomic
   instructions (e.g. lock addq) for GCOV counter updates, which is
   exactly what prevents the counter/induction-variable merging and
   the observed 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.

 - No functional change on all previously tested architectures (see
   Testing below).

History
-------

v1 (per-subsystem gcov submission):
  https://lore.kernel.org/lkml/20260402141831.1437357-1-khorenko@virtuozzo.com/T/#t

This was originally posted as a zlib-only fix:
  https://lore.kernel.org/lkml/20260330143256.306326-1-khorenko@virtuozzo.com/T/#t

During review, it was suggested to apply the flag globally instead of
per-subsystem, as it not only fixes the observed crash but makes GCOV
coverage data more consistent overall.  A combined series was posted:
  https://lore.kernel.org/lkml/20260401142020.1434243-1-khorenko@virtuozzo.com/T/#t

That combined series was then split per subsystem as requested by
reviewers; this is v2 of the gcov piece.

The GCC bug report for the underlying compiler issue:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124749

The crash
---------

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=prefer-atomic forces atomic
counter updates on supported targets 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).

Assembly-verified that -fprofile-update=prefer-atomic prevents
counter-IV merging in inflate_fast() on both compiler versions (emits
the same atomic lock addq sequence as plain -fprofile-update=atomic on
x86_64).

Also tested by Peter Oberparleiter (on the v1 payload, which differs
only in the 'prefer-' prefix on the GCC flag):

Quote: "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)."

Konstantin Khorenko (1):
  gcov: use atomic counter updates to fix concurrent access crashes

 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.43.5

[PATCH v2] 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=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@virtuozzo.com>
Tested-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 54e1ae602000..402c640120ac 100644
--- a/Makefile
+++ b/Makefile
@@ -824,7 +824,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
 
-- 
2.43.5

Re: [PATCH v2] gcov: use atomic counter updates to fix concurrent access crashes

[Konstantin Khorenko]

https://sashiko.dev/#/patchset/20260422125112.3583649-1-khorenko%40virtuozzo.com

 > The kernel supports gcc versions down to 8.1.0, but the -fprofile-update=prefer-atomic compiler 
flag was introduced in gcc 11.


-fprofile-update=prefer-atomic has been available since GCC 7.1.0 (May 2017).

https://github.com/gcc-mirror/gcc/blob/releases/gcc-7.1.0/gcc/common.opt#L1981-L1995
<<<<<<<<<<<<<<<<<
         EnumValue
         Enum(profile_update) String(prefer-atomic) Value(PROFILE_UPDATE_PREFER_ATOMIC)
 >>>>>>>>>>>>>>>>>

So any GCC that can build the current kernel accepts -fprofile-update=prefer-atomic.

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team

Re: [PATCH v2] gcov: use atomic counter updates to fix concurrent access crashes

[Arnd Bergmann]

On Wed, Apr 22, 2026, at 14:51, Konstantin Khorenko wrote:
> @@ -824,7 +824,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

Unfortunately, this causes link failures in a few files that
end up trying to use the libgcc atomic function calls. From
my randconfig builds with gcc-16, I have so far seen:

x86_64-linux-ld: io_uring/io_uring.o: in function `io_uring_fill_params':
io_uring.c:(.text+0x40): undefined reference to `__atomic_fetch_add_8'

aarch64-linux-ld: io_uring/io_uring.o: in function `io_req_sqe_copy':
io_uring.c:(.text+0x2c): undefined reference to `__aarch64_ldadd8_relax'

aarch64-linux-ld: kernel/trace/trace_selftest_dynamic.o: in function `trace_selftest_dynamic_test_func':
trace_selftest_dynamic.c:(.text.trace_selftest_dynamic_test_func+0x24): undefined reference to `__aarch64_ldadd8_relax'

aarch64-linux-ld: trace_clock.c:(.text.trace_clock_global+0x3c): undefined reference to `__aarch64_ldadd8_relax'

ERROR: modpost: "__atomic_fetch_add_8" [kernel/trace/ring_buffer_benchmark.ko] undefined!
ERROR: modpost: "__aarch64_ldadd8_relax" [kernel/trace/preemptirq_delay_test.ko] undefined!
ERROR: modpost: "__aarch64_ldadd8_relax" [kernel/trace/synth_event_gen_test.ko] undefined!
ERROR: modpost: "__aarch64_ldadd8_relax" [kernel/trace/remote_test.ko] undefined!

ERROR: modpost: "__aarch64_ldadd8_relax" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!

Since I build only with CONFIG_COMPILE_TEST=y, it looks like these
are the files that explictly enable GCOV, and likely all others
would run into the same issue.

      Arnd

Re: [PATCH v2] gcov: use atomic counter updates to fix concurrent access crashes

[Peter Oberparleiter]

On 28.04.2026 22:56, Arnd Bergmann wrote:
> On Wed, Apr 22, 2026, at 14:51, Konstantin Khorenko wrote:
>> @@ -824,7 +824,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
> 
> Unfortunately, this causes link failures in a few files that
> end up trying to use the libgcc atomic function calls. From
> my randconfig builds with gcc-16, I have so far seen:
> 
> x86_64-linux-ld: io_uring/io_uring.o: in function `io_uring_fill_params':
> io_uring.c:(.text+0x40): undefined reference to `__atomic_fetch_add_8'
> 
> aarch64-linux-ld: io_uring/io_uring.o: in function `io_req_sqe_copy':
> io_uring.c:(.text+0x2c): undefined reference to `__aarch64_ldadd8_relax'
> 
> aarch64-linux-ld: kernel/trace/trace_selftest_dynamic.o: in function `trace_selftest_dynamic_test_func':
> trace_selftest_dynamic.c:(.text.trace_selftest_dynamic_test_func+0x24): undefined reference to `__aarch64_ldadd8_relax'
> 
> aarch64-linux-ld: trace_clock.c:(.text.trace_clock_global+0x3c): undefined reference to `__aarch64_ldadd8_relax'
> 
> ERROR: modpost: "__atomic_fetch_add_8" [kernel/trace/ring_buffer_benchmark.ko] undefined!
> ERROR: modpost: "__aarch64_ldadd8_relax" [kernel/trace/preemptirq_delay_test.ko] undefined!
> ERROR: modpost: "__aarch64_ldadd8_relax" [kernel/trace/synth_event_gen_test.ko] undefined!
> ERROR: modpost: "__aarch64_ldadd8_relax" [kernel/trace/remote_test.ko] undefined!
> 
> ERROR: modpost: "__aarch64_ldadd8_relax" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
> 
> Since I build only with CONFIG_COMPILE_TEST=y, it looks like these
> are the files that explictly enable GCOV, and likely all others
> would run into the same issue.

So the use of -fprofile-update=prefer-atomic in the kernel causes link
errors on systems for which GCC does not support built-in atomic ops for
the 64 bit profiling data type. Your test triggers this due to
CONFIG_COMPILE_TEST but as you stated this would hit all GCOV users on
such systems.

I can see multiple approaches to address this issue:

1. Drop the patch
   => not preferred - crash would still remain, and the consistency
   improvements would be lost
2. Make -fprofile-update dependent on !COMPILE_TEST
   => would enable randconfig compiles with COMPILE_TEST=y
3. Make -fprofile-update dependent on the result of a test-compile of a
   user space test program (not sure if there is an easier way to
   determine whether built-in atomic ops are available for the gcov
   type)
   => would enable fix + improvements for all environments, where
   they are supported, but requires slightly more complex changes in
   linux/Makefile
4. Provide wrappers for GCC libatomic => kernel atomic functions
   => would enable fix + improvements for GCOV users on all systems
   But: bigger change + linker errors mentioned above suggest that
   GCC libatomic function names may be arch specific which makes this
   approach more complex

I tend towards option 3 or 2, but I'm also open for other ideas.

@Konstantin Khorenko: would you be willing to work on this as the author
of the original fix?


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

Re: [PATCH v2] gcov: use atomic counter updates to fix concurrent access crashes

[Arnd Bergmann]

On Thu, May 7, 2026, at 15:31, Peter Oberparleiter wrote:
> On 28.04.2026 22:56, Arnd Bergmann wrote:
>> On Wed, Apr 22, 2026, at 14:51, Konstantin Khorenko wrote:
>> 
>> ERROR: modpost: "__atomic_fetch_add_8" [kernel/trace/ring_buffer_benchmark.ko] undefined!
>> ERROR: modpost: "__aarch64_ldadd8_relax" [kernel/trace/preemptirq_delay_test.ko] undefined!
>> ERROR: modpost: "__aarch64_ldadd8_relax" [kernel/trace/synth_event_gen_test.ko] undefined!
>> ERROR: modpost: "__aarch64_ldadd8_relax" [kernel/trace/remote_test.ko] undefined!
>> 
>> ERROR: modpost: "__aarch64_ldadd8_relax" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
>> 
>> Since I build only with CONFIG_COMPILE_TEST=y, it looks like these
>> are the files that explictly enable GCOV, and likely all others
>> would run into the same issue.
>
> So the use of -fprofile-update=prefer-atomic in the kernel causes link
> errors on systems for which GCC does not support built-in atomic ops for
> the 64 bit profiling data type. Your test triggers this due to
> CONFIG_COMPILE_TEST but as you stated this would hit all GCOV users on
> such systems.
>
> I can see multiple approaches to address this issue:
>
> 1. Drop the patch
>    => not preferred - crash would still remain, and the consistency
>    improvements would be lost

This might be an option for the moment, until we have a better
solution though.

> 2. Make -fprofile-update dependent on !COMPILE_TEST
>    => would enable randconfig compiles with COMPILE_TEST=y

This would still leave the same build failure for any actual users
on the affected systems (x86-64 and arm64 at least), right?

> 3. Make -fprofile-update dependent on the result of a test-compile of a
>    user space test program (not sure if there is an easier way to
>    determine whether built-in atomic ops are available for the gcov
>    type)
>    => would enable fix + improvements for all environments, where
>    they are supported, but requires slightly more complex changes in
>    linux/Makefile

This seems fine to me, but I wonder which architectures actually
support it at the moment. I assume you are successfully using it
on s390, but if the two most commonly used architectures don't
support it, it's not clear to me who else actually can.

> 4. Provide wrappers for GCC libatomic => kernel atomic functions
>    => would enable fix + improvements for GCOV users on all systems
>    But: bigger change + linker errors mentioned above suggest that
>    GCC libatomic function names may be arch specific which makes this
>    approach more complex

The lack of libatomic support in the kernel has come up a few times
before, when driver writers attempted to use standard C11 _Atomic
variables. I think so far we have always reverted back to the kernel's
own atomic_t implementation here, mostly because kernel developers
are more comfortable with the existing memory model, which seems
to have some subtle differences from the C11 semantics.

      Arnd

Re: [PATCH v2] gcov: use atomic counter updates to fix concurrent access crashes

[Andrew Morton]

On Thu, 07 May 2026 15:43:01 +0200 "Arnd Bergmann" <arnd@arndb.de> wrote:

> > 1. Drop the patch
> >    => not preferred - crash would still remain, and the consistency
> >    improvements would be lost
> 
> This might be an option for the moment, until we have a better
> solution though.

Compromise: I temporarily moved this patch ("gcov: use atomic counter
updates to fix concurrent access crashes") into mm-git's mm-new branch.
So the patch still exists, is still under test by a few MM developers
but is no longer in linux-next.

Re: [PATCH v2] gcov: use atomic counter updates to fix concurrent access crashes

[Konstantin Khorenko]

On 5/7/26 15:31, Peter Oberparleiter wrote:
> On 28.04.2026 22:56, Arnd Bergmann wrote:
...
> 
> I can see multiple approaches to address this issue:
> 
> 1. Drop the patch
>     => not preferred - crash would still remain, and the consistency
>     improvements would be lost
> 2. Make -fprofile-update dependent on !COMPILE_TEST
>     => would enable randconfig compiles with COMPILE_TEST=y
> 3. Make -fprofile-update dependent on the result of a test-compile of a
>     user space test program (not sure if there is an easier way to
>     determine whether built-in atomic ops are available for the gcov
>     type)
>     => would enable fix + improvements for all environments, where
>     they are supported, but requires slightly more complex changes in
>     linux/Makefile
> 4. Provide wrappers for GCC libatomic => kernel atomic functions
>     => would enable fix + improvements for GCOV users on all systems
>     But: bigger change + linker errors mentioned above suggest that
>     GCC libatomic function names may be arch specific which makes this
>     approach more complex
> 
> I tend towards option 3 or 2, but I'm also open for other ideas.
> 
> @Konstantin Khorenko: would you be willing to work on this as the author
> of the original fix?


Peter, Arnd,

Thank you very much for taking a look here.

I'll work on option 3 (compile-time check).

If i understand this correctly the idea is to verify at build time
whether the compiler actually inlines 64-bit atomic increments or
emits calls to libatomic helpers, and only add
-fprofile-update=prefer-atomic when it's safe.

I did a quick test: with GCC 14.2.1 in -m32 mode (i386 target), 64-bit
atomics are fully inlined via lock cmpxchg8b - no __atomic_fetch_add_8
call is generated.

So this might actually be a GCC-16 regression in codegen rather than
an inherent architecture limitation.

I'm currently rebuilding GCC trunk to verify.

Arnd,
could you please share the two .config files that triggered the link
failures (the x86_64 one with __atomic_fetch_add_8 and the aarch64 one
with __aarch64_ldadd8_relax)?
That could make my life a bit easier. :)


Thank you,
Konstantin

Re: [PATCH v2] gcov: use atomic counter updates to fix concurrent access crashes

[Konstantin Khorenko]

On 5/9/26 13:50, Konstantin Khorenko wrote:
...
> 
> Arnd,
> could you please share the two .config files that triggered the link
> failures (the x86_64 one with __atomic_fetch_add_8 and the aarch64 one
> with __aarch64_ldadd8_relax)?
> That could make my life a bit easier. :)

Please, disregard my request, already found robot reports with links to configs.

Sent v3 with "option 3" implemented already.


Thank you,
Konstantin

Re: [PATCH v2] gcov: use atomic counter updates to fix concurrent access crashes

[Arnd Bergmann]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

On Sat, May 9, 2026, at 13:50, Konstantin Khorenko wrote:
> On 5/7/26 15:31, Peter Oberparleiter wrote:
>> On 28.04.2026 22:56, Arnd Bergmann wrote:
>
> So this might actually be a GCC-16 regression in codegen rather than
> an inherent architecture limitation.
....
> could you please share the two .config files that triggered the link
> failures (the x86_64 one with __atomic_fetch_add_8 and the aarch64 one
> with __aarch64_ldadd8_relax)?
> That could make my life a bit easier. :)

I've attached two configs each now, see what you find.

I just realized that these tests were still using a prerelease
compiler, so it's even possible that the gcc-16.1 release is
clean. I should build the next set of cross-compilers soon,
and will be able to retest then.

    Arnd

[-- Attachment #2: gcov-configs.tar.gz --]
[-- Type: application/gzip, Size: 182449 bytes --]

Re: [PATCH v2] gcov: use atomic counter updates to fix concurrent access crashes

[Konstantin Khorenko]

On 5/9/26 17:14, Arnd Bergmann wrote:
> On Sat, May 9, 2026, at 13:50, Konstantin Khorenko wrote:
>> On 5/7/26 15:31, Peter Oberparleiter wrote:
>>> On 28.04.2026 22:56, Arnd Bergmann wrote:
>>
>> So this might actually be a GCC-16 regression in codegen rather than
>> an inherent architecture limitation.
> ....
>> could you please share the two .config files that triggered the link
>> failures (the x86_64 one with __atomic_fetch_add_8 and the aarch64 one
>> with __aarch64_ldadd8_relax)?
>> That could make my life a bit easier. :)
> 
> I've attached two configs each now, see what you find.
> 
> I just realized that these tests were still using a prerelease
> compiler, so it's even possible that the gcc-16.1 release is
> clean. I should build the next set of cross-compilers soon,
> and will be able to retest then.

Hi Arnd,

thank you for sending those configs.

All 4 previously failing configs were successfully built with the new patch applied
(on top of 5d6919055dec (tag: v7.1-rc3, origin/master, origin/HEAD) Linux 7.1-rc3):

   * 0x5AB716A4 - arm64, UP (no SMP), GCOV_PROFILE_URING + GCOV_PROFILE_RDS: build OK
     (make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-)
   * 0xD01A6C73 - x86_32 (i386), SMP, GCOV_PROFILE_URING + GCOV_PROFILE_RDS: build OK
     (make ARCH=i386)
   * 0xD21DABF - arm64, UP (no SMP), GCOV_PROFILE_URING: build OK
   * 0xFE5738DD - x86_32 (i386), UP (no SMP), GCOV_PROFILE_URING + GCOV_PROFILE_FTRACE: build OK

Previously these configs failed at link stage with undefined references to __aarch64_ldadd8_relax 
(arm64) and __atomic_fetch_add_8 (x86_32), caused by 64-bit atomic operations inserted by GCOV 
instrumentation. The new patch resolves all of these.

Note: the original failures were reported with gcc-16.0.1.2-nolibc cross toolchain;
my test builds used gcc-12.1.1 (aarch64-linux-gnu) and gcc-11.4.1 (x86),
but i really think this does not matter here:
i've checked in all 4 cases -fprofile-update=prefer-atomic was not used - try-run fence worked fine.

And when i've built the 0xD01A6C73-config switched to x86_64 (# CONFIG_X86_32 is not set, 
CONFIG_X86_64=y and CONFIG_64BIT=y), the build passed and -fprofile-update=prefer-atomic was used.

--
Thank you,
Konstantin