From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 695CC72 for ; Wed, 8 Sep 2021 21:59:04 +0000 (UTC) Received: by mail-wr1-f45.google.com with SMTP id u16so5410787wrn.5 for ; Wed, 08 Sep 2021 14:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=+LR8frgXEe3ow5R83HHc128uph7ex7SBJh9j6e+S9jU=; b=Db08IbxJ13EWKYQNGZ2BEuYsakhUSoIWFEo23AxCjh0j+YYZUAYir81XobnmhdiQFC 1iSVB74cCVzPUS1vGu59yP4rT4pCrd4YDNYH7j7c3dsrwlrdxSnP4oy0loI6+6CtalWJ LKXTNXMJVTgRiy0U9o3cqCOmJTqWvfPGpCabxpOLQ71sUgtL4uo66+t8MWgMPhYieet8 sbMaCQLCKSjeTPhIL7lYpAIf6SX9Jo+Y3p5sQFLYc1YSIVTP9WSd2LfIphpbBDvU1LVL 4TTP9wwvFOJnOuTkfJZQqhMJ1gBJZD4IDEXw290MmI/VunlC/CDYSxsp1JwZn9nDgCqs 99DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=+LR8frgXEe3ow5R83HHc128uph7ex7SBJh9j6e+S9jU=; b=0DJpHcRQn1E/AaCFRBqyZrPP3Iq/IMVx/4YYUXx4LGDDaqRmRX+/daPQnAQ3thJLHy 0OF/T+E5RYk5sUy9ikFluj1Y9gYZoEohfCr2ThFZbQF6ruwi3bXNkVgWnnHyFotEKsXl dK96WS9Z37DL9VjcEkgWn+90Fvn2+WOX9Z1KNfuxx3YJW8XzhaogjLA+AjMoHaW27Nss iizL1OI/9i+SMXZpN5DO6mhW1J29CTfuwc+RQHMM/7cposMljn8lP+RNmFKasUdPFgtv /BJ+cxZ7S3EwTRZn9GNd9+MjgSDB3owzpIVEhx0+KvRizHvZQYR/7ptyuvt6K1nGo/vL 41zA== X-Gm-Message-State: AOAM530RmRPa9mspu1gxM651MM4VVgHNzVvISPl0YPRBhZDm6JGErvw3 KHkjnY761cqSVWtkgu/5l8Dt6g== X-Google-Smtp-Source: ABdhPJy9LuBylSkfGDLomcMbGliUY/gfERj/SWVa0XWOQWuMBf30BqzMK/CEeBFTW6NaaPpKmnfwMg== X-Received: by 2002:adf:f208:: with SMTP id p8mr418298wro.379.1631138342436; Wed, 08 Sep 2021 14:59:02 -0700 (PDT) Received: from elver.google.com ([2a00:79e0:15:13:6c42:a08d:7652:61ef]) by smtp.gmail.com with ESMTPSA id o10sm358689wrc.16.2021.09.08.14.59.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Sep 2021 14:59:01 -0700 (PDT) Date: Wed, 8 Sep 2021 23:58:56 +0200 From: Marco Elver To: Guenter Roeck Cc: Nathan Chancellor , Arnd Bergmann , Linus Torvalds , Linux Kernel Mailing List , llvm@lists.linux.dev, Nick Desaulniers , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv@lists.infradead.org, Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Andrey Konovalov , kasan-dev@googlegroups.com Subject: Re: [PATCH] Enable '-Werror' by default for all kernel builds Message-ID: References: <20210906142615.GA1917503@roeck-us.net> <75a10e8b-9f11-64c4-460b-9f3ac09965e2@roeck-us.net> Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75a10e8b-9f11-64c4-460b-9f3ac09965e2@roeck-us.net> User-Agent: Mutt/2.0.5 (2021-01-21) On Wed, Sep 08, 2021 at 02:16PM -0700, Guenter Roeck wrote: > On 9/8/21 1:55 PM, Nathan Chancellor wrote: [...] > > I have started taking a look at these. Most of the allmodconfig ones > > appear to be related to CONFIG_KASAN, which is now supported for > > CONFIG_ARM. > > > > Would it make sense to make KASAN depend on !COMPILE_TEST ? > After all, the point of KASAN is runtime testing, not build testing. It'd be good to avoid. It has helped uncover build issues with KASAN in the past. Or at least make it dependent on the problematic architecture. For example if arm is a problem, something like this: --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -71,7 +71,7 @@ config ARM select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6 select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU - select HAVE_ARCH_KASAN if MMU && !XIP_KERNEL + select HAVE_ARCH_KASAN if MMU && !XIP_KERNEL && (!COMPILE_TEST || !CC_IS_CLANG) select HAVE_ARCH_MMAP_RND_BITS if MMU select HAVE_ARCH_PFN_VALID select HAVE_ARCH_SECCOMP More generally, with clang, the problem is known and due to KASAN stack instrumentation (CONFIG_KASAN_STACK): | config KASAN_STACK | bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST | depends on KASAN_GENERIC || KASAN_SW_TAGS | depends on !ARCH_DISABLE_KASAN_INLINE | default y if CC_IS_GCC | help | The LLVM stack address sanitizer has a know problem that | causes excessive stack usage in a lot of functions, see | https://bugs.llvm.org/show_bug.cgi?id=38809 | Disabling asan-stack makes it safe to run kernels build | with clang-8 with KASAN enabled, though it loses some of | the functionality. | This feature is always disabled when compile-testing with clang | to avoid cluttering the output in stack overflow warnings, | but clang users can still enable it for builds without | CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe | to use and enabled by default. | If the architecture disables inline instrumentation, stack | instrumentation is also disabled as it adds inline-style | instrumentation that is run unconditionally. This is already disabled if COMPILE_TEST and building with clang. As far as I know, there's no easy fix for clang and it's been discussed many times over with LLVM devs. Thanks, -- Marco