Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Arnd Bergmann <arnd@kernel.org>
Cc:     Arnd Bergmann <arnd@arndb.de>,
        =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= 
        <u.kleine-koenig@pengutronix.de>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Kees Cook <keescook@chromium.org>,
        linux-kbuild@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Nathan Chancellor <nathan@kernel.org>,
        linux-kernel@vger.kernel.org
Subject: [PATCH] [RFC] Kbuild: change CONFIG_FRAME_WARN for 32-bit
Date:   Fri, 17 Jun 2022 17:08:53 +0200
Message-Id: <20220617150922.1878926-1-arnd@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
To:     unlisted-recipients:; (no To-header on input)
Precedence: bulk

From: Arnd Bergmann <arnd@arndb.de>

The introduction of CONFIG_GCC_PLUGIN_LATENT_ENTROPY raised the
warning limit for 32-bit architectures to a much higher value in
2016. Initially this had no effect for Arm machines as their kernels
tend to be cross-compiled, and the feature detection for the plugin did
not work with common cross compilers.

I could not find the original regression report that led to the warning
limit getting raised, but I have been unable to reproduce this with gcc-12
and linux-5.18 -- all frame sizes appear to be be below the normal 1024
byte limit on at least arm32 and i386.

However, the KASAN feature introduced later on does raise the frame size
of a number of functions above the warning limit, in almost all cases to
somewhere below 1280 bytes. The effect is that an arm allmodconfig build
produces no warnings because of the check for the latent entropy plugin,
but a normal KASAN based build with gcc does produce build warnings or
failures when CONFIG_WERROR is set.

The 1280 byte limit is an arbitrary choice here, as it disables almost
all warnings but leaves a few outliers that are probably better addressed
with code changes. There are a number of functions that are just below the
normal 1024 byte limit at the moment, and an extra 256 bytes for those
is within the expectation, but more than that is probably an indication
of a bad design or a real bug.

Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: linux-kbuild@vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 lib/Kconfig.debug | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 3da5f9acb966..8a3afd837e99 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -387,9 +387,9 @@ endif # DEBUG_INFO
 config FRAME_WARN
 	int "Warn for stack frames larger than"
 	range 0 8192
-	default 2048 if GCC_PLUGIN_LATENT_ENTROPY
 	default 2048 if PARISC
 	default 1536 if (!64BIT && XTENSA)
+	default 1280 if (!64BIT && KASAN_STACK)
 	default 1024 if !64BIT
 	default 2048 if 64BIT
 	help
-- 
2.29.2