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

["Arnd Bergmann" <arnd@arndb.de>]

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