Re: [PATCH] Enable '-Werror' by default for all kernel builds
From: Marco Elver
Date: Wed Sep 08 2021 - 17:59:06 EST
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:
@@ -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
More generally, with clang, the problem is known and due to 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
| The LLVM stack address sanitizer has a know problem that
| causes excessive stack usage in a lot of functions, see
| 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.