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