From: Konstantin Khorenko <khorenko@virtuozzo.com>
To: Peter Oberparleiter <oberpar@linux.ibm.com>,
Mikhail Zaslonko <zaslonko@linux.ibm.com>,
Nathan Chancellor <nathan@kernel.org>,
Nicolas Schier <nsc@kernel.org>
Cc: "Masahiro Yamada" <masahiroy@kernel.org>,
"Thomas Weißschuh" <linux@weissschuh.net>,
"Arnd Bergmann" <arnd@arndb.de>,
"Steffen Klassert" <steffen.klassert@secunet.com>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org,
"Konstantin Khorenko" <khorenko@virtuozzo.com>,
"Pavel Tikhomirov" <ptikhomirov@virtuozzo.com>,
"Vasileios Almpanis" <vasileios.almpanis@virtuozzo.com>,
"Jakub Kicinski" <kuba@kernel.org>
Subject: [PATCH 0/1] gcov: add -fprofile-update=atomic to fix concurrent access crashes
Date: Thu, 2 Apr 2026 17:18:30 +0300 [thread overview]
Message-ID: <20260402141831.1437357-1-khorenko@virtuozzo.com> (raw)
This patch adds -fprofile-update=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.
History
-------
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 is now split per subsystem as requested by
reviewers.
The GCC bug report for the underlying compiler issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124749
Dependencies
------------
This patch requires the following preparatory fixes to be applied first,
otherwise CONFIG_GCOV_PROFILE_ALL=y builds will fail:
- net: fix skb_ext BUILD_BUG_ON failures with GCOV (sent to netdev):
__no_profile on skb_ext_total_length() and skb_extensions_init()
https://lore.kernel.org/lkml/20260402140558.1437002-1-khorenko@virtuozzo.com/T/#t
- iommu/generic_pt: disable GCOV for iommu_amdv1.o (sent to iommu):
GCOV_PROFILE_iommu_amdv1.o := n
https://lore.kernel.org/lkml/20260402141012.1437095-1-khorenko@virtuozzo.com/T/#t
Without those patches, -fprofile-update=atomic prevents GCC from
constant-folding expressions inside profiled inline functions, breaking
BUILD_BUG_ON / FIELD_PREP compile-time checks.
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=atomic forces atomic counter
updates 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). Both fail without the full set
of patches, both succeed with all three series applied.
Assembly-verified that -fprofile-update=atomic prevents counter-IV
merging in inflate_fast() on both compiler versions.
Also tested by Peter Oberparleiter:
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
next reply other threads:[~2026-04-02 14:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-02 14:18 Konstantin Khorenko [this message]
2026-04-02 14:18 ` [PATCH] gcov: use atomic counter updates to fix concurrent access crashes Konstantin Khorenko
2026-04-06 19:37 ` Nathan Chancellor
2026-04-09 8:11 ` Peter Oberparleiter
2026-04-15 10:19 ` Andrew Morton
2026-04-11 14:17 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260402141831.1437357-1-khorenko@virtuozzo.com \
--to=khorenko@virtuozzo.com \
--cc=arnd@arndb.de \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=masahiroy@kernel.org \
--cc=nathan@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nsc@kernel.org \
--cc=oberpar@linux.ibm.com \
--cc=ptikhomirov@virtuozzo.com \
--cc=steffen.klassert@secunet.com \
--cc=vasileios.almpanis@virtuozzo.com \
--cc=zaslonko@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.