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

[Konstantin Khorenko <khorenko@virtuozzo.com>]

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