From: Konstantin Khorenko <khorenko@virtuozzo.com>
To: "Peter Oberparleiter" <oberpar@linux.ibm.com>,
"Mikhail Zaslonko" <zaslonko@linux.ibm.com>,
"Thomas Weißschuh" <linux@weissschuh.net>
Cc: Steffen Klassert <steffen.klassert@secunet.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
Masahiro Yamada <masahiroy@kernel.org>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Vasileios Almpanis <vasileios.almpanis@virtuozzo.com>,
Pavel Tikhomirov <ptikhomirov@virtuozzo.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Konstantin Khorenko <khorenko@virtuozzo.com>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>, Arnd Bergmann <arnd@arndb.de>
Subject: [PATCH v3 4/4] gcov: use atomic counter updates to fix concurrent access crashes
Date: Wed, 1 Apr 2026 17:20:20 +0300 [thread overview]
Message-ID: <20260401142020.1434243-5-khorenko@virtuozzo.com> (raw)
In-Reply-To: <20260401142020.1434243-1-khorenko@virtuozzo.com>
GCC's GCOV instrumentation can merge global branch counters with loop
induction variables as an optimization. In inflate_fast(), the inner
copy loops get transformed so that the GCOV counter value is loaded
multiple times to compute the loop base address, start index, and end
bound. Since GCOV counters are global (not per-CPU), concurrent
execution on different CPUs causes the counter to change between loads,
producing inconsistent values and out-of-bounds memory writes.
The crash manifests during IPComp (IP Payload Compression) processing
when inflate_fast() runs concurrently on multiple CPUs:
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
At the crash point, the compiler generated three loads from the same
global GCOV counter (__gcov0.inflate_fast+216) to compute base, start,
and end for an indexed loop. Another CPU modified the counter between
loads, making the values inconsistent — the write went 3.4 MB past a
65 KB buffer.
Add -fprofile-update=atomic to CFLAGS_GCOV at the global level in the
top-level Makefile. This tells GCC that GCOV counters may be
concurrently accessed, causing counter updates to use atomic
instructions (lock addq) instead of plain load/store. This prevents
the compiler from merging counters with loop induction variables.
Applying this globally rather than per-subsystem not only addresses the
observed crash in zlib but makes GCOV coverage data more consistent
overall, preventing similar issues in any kernel code path that may
execute concurrently.
Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 6b1d9fb1a6b4..a55ad668d6ba 100644
--- a/Makefile
+++ b/Makefile
@@ -806,7 +806,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=atomic
endif
export CFLAGS_GCOV
--
2.43.5
next prev parent reply other threads:[~2026-04-01 14:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-01 14:20 [PATCH v3 0/4] gcov: use -fprofile-update=atomic globally to fix concurrent access crashes on GCOV-enabled kernels Konstantin Khorenko
2026-04-01 14:20 ` [PATCH v3 1/4] net: fix skb_ext_total_length() BUILD_BUG_ON with CONFIG_GCOV_PROFILE_ALL Konstantin Khorenko
2026-04-01 14:20 ` [PATCH v3 2/4] net: add __no_profile to skb_extensions_init() for GCOV compatibility Konstantin Khorenko
2026-04-01 14:20 ` [PATCH v3 3/4] iommu/generic_pt: disable GCOV for iommu_amdv1.o Konstantin Khorenko
2026-04-01 14:20 ` Konstantin Khorenko [this message]
2026-04-01 16:55 ` [PATCH v3 4/4] gcov: use atomic counter updates to fix concurrent access crashes Peter Oberparleiter
2026-04-02 1:46 ` [PATCH v3 0/4] gcov: use -fprofile-update=atomic globally to fix concurrent access crashes on GCOV-enabled kernels Jakub Kicinski
2026-04-02 12:48 ` Konstantin Khorenko
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=20260401142020.1434243-5-khorenko@virtuozzo.com \
--to=khorenko@virtuozzo.com \
--cc=arnd@arndb.de \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=horms@kernel.org \
--cc=jpoimboe@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=masahiroy@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=oberpar@linux.ibm.com \
--cc=pabeni@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox