From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.virtuozzo.com (relay.virtuozzo.com [130.117.225.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2BF4B207DF7; Thu, 2 Apr 2026 14:18:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=130.117.225.111 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775139521; cv=none; b=CwUccKuVXpwcDvB/6NBH7zfyUkMCXpjy7iDlpx14AnUDP7MbbYrjfzLwOgwy5YocpdTPP013hWR02WHMIaaCqtKin1fnpYwUbiI3vBHdyRNJ05mU2612wCA7J8kR9LB45LLjRTQ8NvD+ZCk9ekudD4JyhJa5uqCjeGzckOLwg/k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775139521; c=relaxed/simple; bh=bIIn3wyBhTaGlRtuKDocl//BDHKJ8AKUQ1pFkXdpTP0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=tm8uRUygU/tliMquEZmIEZ/nvf3RQLvsZI8tD9MQtcXnDwRvepNl0A8yLixHSEELuY+RU4yYzIVDR5hwL20tC/Q9RMvuBeJ43c9D/Fnj8rUks59I6lJsrMf7WMsreozhkIQvZtN43Ya+ZJk37uScrn2bGCMnhxMmFbpae8khh4E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=virtuozzo.com; spf=pass smtp.mailfrom=virtuozzo.com; dkim=pass (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b=NEJMkt9u; arc=none smtp.client-ip=130.117.225.111 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=virtuozzo.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=virtuozzo.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="NEJMkt9u" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=virtuozzo.com; s=relay; h=Content-Type:MIME-Version:Message-ID:Date:Subject :From; bh=5LRbehgey3k3jFMPv3TD68ZHCD/cnTWjEGBb7/+0Nas=; b=NEJMkt9u4W+CVlQ/aHM uYZh+QziFfyz+Le+clFvG+X8YrxmAtIgpgUjHjrErIIRLKXqz4/R1SP6YH8hSzdaE9BSabVFRByFK NgAm0fYYh7ombhRM2w1WyoYRSqLAMOsRb6eLwno5sdq4zK/q3ibua04pTKAy4xJA8eFDUprXbNWZQ jfiB8pEOdchcEsgOpU4/v+4thFuLarSC9zAlOaNtRigyXliolMM6qnqlXi7o8C37GyG6Y/wu5T64Y pGD0NSwtNKv22i5ZagHChq49JJmkA7PANY2fbPoO1C9x1xE1T1Fajlb6CYL+EFkt7TYRPv8W/5Wz/ owg1hcTm1HZnXow==; Received: from [130.117.225.5] (helo=finist-alma9.vzint.dev) by relay.virtuozzo.com with esmtp (Exim 4.96) (envelope-from ) id 1w8IqH-003geR-2b; Thu, 02 Apr 2026 16:18:30 +0200 From: Konstantin Khorenko To: Peter Oberparleiter , Mikhail Zaslonko , Nathan Chancellor , Nicolas Schier Cc: Masahiro Yamada , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , Arnd Bergmann , Steffen Klassert , Herbert Xu , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Konstantin Khorenko , Pavel Tikhomirov , Vasileios Almpanis , Jakub Kicinski Subject: [PATCH] gcov: use atomic counter updates to fix concurrent access crashes Date: Thu, 2 Apr 2026 17:18:31 +0300 Message-ID: <20260402141831.1437357-2-khorenko@virtuozzo.com> X-Mailer: git-send-email 2.43.5 In-Reply-To: <20260402141831.1437357-1-khorenko@virtuozzo.com> References: <20260402141831.1437357-1-khorenko@virtuozzo.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Tested-by: Peter Oberparleiter Reviewed-by: Peter Oberparleiter --- 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