Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp2980292pxb; Sun, 3 Oct 2021 11:07:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxkRKDy/3ef5adhgTCQG5udhyuJqIBO2rfuPNN0GpBt+mxHVUGjnYHBSnUGUax1XI4bn7N4 X-Received: by 2002:a17:90a:51:: with SMTP id 17mr25894692pjb.185.1633284429600; Sun, 03 Oct 2021 11:07:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633284429; cv=none; d=google.com; s=arc-20160816; b=TsXai94TmphCfcc+98QO7y5C1Mxbby9JyhAnSFyh3hbrf9ca+PVdR1/BPzqakIGR12 uDzXFEftNaSz1AaVwz8EE4P0WR1BJ0tZmfrr6AJILxVPOYvxKgbWsAZfspbJECV0KcUq FPt1Bl3rUFNZv2UA75g6BIvXf9gSFegiaATNDTU9aU2bJYUxB38F38AAAMIN7jQU7vbo sJKh774Y+NhM4z8vw5YcKrr+5rgr1AhU/oamMUppbslGuPPmvwjA26Zh2vkfUFqSCiYC 9EW2R2UW7G/gCzmxFhdkZPRD2AzBgnM5o35FcyXauPAeMLxDVAgt5jS7EtH9lpTZ0Duf iIFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=0t/uC6UY+gZWkI7u9HEXsrryIwtnXmLh6shI3cfFXHw=; b=sVLgDdtXFfmRho4G4lSi7yGvfg50CaRGeswEMrJw0jtvTon9d0vfWxKQnbVYYw6Nmw MT2ftk4qb86LePp/YAubZ8+oU017HPymbzxiqMkgl3gyBp4peS5R1gEMk+PrJJ4J7Dw3 DRFoznQVAiRezXsbZmYD25PzkHDxAxmEFE7OdRCh/Zx+8vJe/0JxXasLF27Hsu6PbZmD mmvJEIJg735QNCO8wz9aTABcHPfUXCzFQGDPr2VTYkTn/hWvHVBwIdp4Za70tPe6bQFX +8fV0VIRC9Xds/Ie55jah10DKeUOt/knb0cXHK6Xp7qsl+Anq3r8XE0Zpo5OdRtQtyZl gVdg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=cB6WICj3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o24si3702452pgv.451.2021.10.03.11.06.55; Sun, 03 Oct 2021 11:07:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=cB6WICj3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231280AbhJCSGx (ORCPT + 99 others); Sun, 3 Oct 2021 14:06:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230519AbhJCSGw (ORCPT ); Sun, 3 Oct 2021 14:06:52 -0400 Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EFE7EC0613EC for ; Sun, 3 Oct 2021 11:05:04 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id y197so17676551iof.11 for ; Sun, 03 Oct 2021 11:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0t/uC6UY+gZWkI7u9HEXsrryIwtnXmLh6shI3cfFXHw=; b=cB6WICj3ZrwgOR0Ic+R8lmr9MqGCJSjbqzjS/sDhbyud/r8u+UnfjPxTCJTSLWRt4+ V6y5PAv6L4Yq4CsIjP35UkZ7PCt6QdkKRYUPTYH04s3mtu0sGObyz0XPpFcWpMtrp79D Rgqo+nD95CxYkJutsZiIUFKvP02dN0/JQnZRd5zW0bwO4SEUjjSJdDLmimfOuxqlMDA1 Jo1gCyYZPpYEouHk0QUNmV2ciOagnuF8WJqWOlL+yvMD7LEqD6+XjGdodlNdIsZch40w cVUo7foe41DX1dcfeB04jXSdxKrtIpHy+WMW51vGTDUKxqz26DewSm5PQZ5gLJWXaOwh F5gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0t/uC6UY+gZWkI7u9HEXsrryIwtnXmLh6shI3cfFXHw=; b=HU0uu/Dfa8ede/sjj9M7aQgvziYju+eyGX5MsENXYPYOI0s69Zs0ay2105vlvVweJU KVr+8IrncQfqoO2XZj+lCwvNVXcM+tay+tekUQqDgD2mBbrji8+4Xkwlg3PZ11P5ZW4U Zm8eWq2vy0xT+pT4e+etcrrjjljVeNfA31NnTCId3fUOTBPI8MthuD+jUwaWiPQGZoyb dLEBWz72dqhstgTAjXYUzvSHUo35si9pK0TruXWC6I6oTjw2KB6K1BV/Gcrlp+yylscZ jl0b0X8GhTyc9WXNidxGkxM+l5iDRlxFeEMw31yvhQcz03A6ccmxm7s9pqcTMszkL7wK r3QA== X-Gm-Message-State: AOAM533ohNtQuwJAPm2rk8XkiVgyp7W4/SaHDzfpOFoptcUpHPge8AwG jYTONOOUhKYucxBmEg+LzH4zgb0SOevRjG1r2MlJOhClxCrY8A== X-Received: by 2002:a6b:c38d:: with SMTP id t135mr6528600iof.99.1633284304078; Sun, 03 Oct 2021 11:05:04 -0700 (PDT) MIME-Version: 1.0 References: <20210922205525.570068-1-nathan@kernel.org> In-Reply-To: <20210922205525.570068-1-nathan@kernel.org> From: Andrey Konovalov Date: Sun, 3 Oct 2021 20:04:53 +0200 Message-ID: Subject: Re: [PATCH] kasan: Always respect CONFIG_KASAN_STACK To: Nathan Chancellor , Andrey Ryabinin , Marco Elver Cc: Alexander Potapenko , Dmitry Vyukov , Nick Desaulniers , Arnd Bergmann , kasan-dev , LKML , llvm@lists.linux.dev Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 22, 2021 at 10:55 PM Nathan Chancellor wrote: > > Currently, the asan-stack parameter is only passed along if > CFLAGS_KASAN_SHADOW is not empty, which requires KASAN_SHADOW_OFFSET to > be defined in Kconfig so that the value can be checked. In RISC-V's > case, KASAN_SHADOW_OFFSET is not defined in Kconfig, which means that > asan-stack does not get disabled with clang even when CONFIG_KASAN_STACK > is disabled, resulting in large stack warnings with allmodconfig: > > drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c:117:12: > error: stack frame size (14400) exceeds limit (2048) in function > 'lb035q02_connect' [-Werror,-Wframe-larger-than] > static int lb035q02_connect(struct omap_dss_device *dssdev) > ^ > 1 error generated. > > Ensure that the value of CONFIG_KASAN_STACK is always passed along to > the compiler so that these warnings do not happen when > CONFIG_KASAN_STACK is disabled. > > Link: https://github.com/ClangBuiltLinux/linux/issues/1453 > References: 6baec880d7a5 ("kasan: turn off asan-stack for clang-8 and earlier") > Signed-off-by: Nathan Chancellor > --- > scripts/Makefile.kasan | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan > index 801c415bac59..b9e94c5e7097 100644 > --- a/scripts/Makefile.kasan > +++ b/scripts/Makefile.kasan > @@ -33,10 +33,11 @@ else > CFLAGS_KASAN := $(CFLAGS_KASAN_SHADOW) \ > $(call cc-param,asan-globals=1) \ > $(call cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \ > - $(call cc-param,asan-stack=$(stack_enable)) \ > $(call cc-param,asan-instrument-allocas=1) > endif This part of code always looked weird to me. Shouldn't we be able to pull all these options out of the else section? Then, the code structure would make sense: first, try applying KASAN_SHADOW_OFFSET; if failed, use CFLAGS_KASAN_MINIMAL; and then try applying all these options one by one. > +CFLAGS_KASAN += $(call cc-param,asan-stack=$(stack_enable)) > + > endif # CONFIG_KASAN_GENERIC > > ifdef CONFIG_KASAN_SW_TAGS > > base-commit: 4057525736b159bd456732d11270af2cc49ec21f > -- > 2.33.0.514.g99c99ed825 >