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