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

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