[PATCH] kasan: push back KASAN_STACK detection to clang-10

[PATCH] kasan: push back KASAN_STACK detection to clang-10

[Arnd Bergmann]

asan-stack mode still uses dangerously large kernel stacks of
tens of kilobytes in some drivers, and it does not seem that anyone
is working on the clang bug.

Let's push this back to clang-10 for now so users don't run into
this by accident, and we can test-build allmodconfig kernels using
clang-9 without drowning in warnings.

Link: https://bugs.llvm.org/show_bug.cgi?id=38809
Fixes: 6baec880d7a5 ("kasan: turn off asan-stack for clang-8 and earlier")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 lib/Kconfig.kasan | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index 4fafba1a923b..2f260bb63d77 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -106,7 +106,7 @@ endchoice
 
 config KASAN_STACK_ENABLE
 	bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
-	default !(CLANG_VERSION < 90000)
+	default !(CLANG_VERSION < 100000)
 	depends on KASAN
 	help
 	  The LLVM stack address sanitizer has a know problem that
-- 
2.20.0

Re: [PATCH] kasan: push back KASAN_STACK detection to clang-10

[Andrey Ryabinin]

On 7/18/19 5:14 PM, Arnd Bergmann wrote:
> asan-stack mode still uses dangerously large kernel stacks of
> tens of kilobytes in some drivers, and it does not seem that anyone
> is working on the clang bug.
> 
> Let's push this back to clang-10 for now so users don't run into
> this by accident, and we can test-build allmodconfig kernels using
> clang-9 without drowning in warnings.
> 
> Link: https://bugs.llvm.org/show_bug.cgi?id=38809
> Fixes: 6baec880d7a5 ("kasan: turn off asan-stack for clang-8 and earlier")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  lib/Kconfig.kasan | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> index 4fafba1a923b..2f260bb63d77 100644
> --- a/lib/Kconfig.kasan
> +++ b/lib/Kconfig.kasan
> @@ -106,7 +106,7 @@ endchoice
>  
>  config KASAN_STACK_ENABLE
>  	bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
> -	default !(CLANG_VERSION < 90000)
> +	default !(CLANG_VERSION < 100000)

Wouldn't be better to make this thing for any clang version? And only when the bug is
finally fixed, specify the clang version which can enable this safely.


>  	depends on KASAN
>  	help
>  	  The LLVM stack address sanitizer has a know problem that
> 

Re: [PATCH] kasan: push back KASAN_STACK detection to clang-10

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

On Thu, Jul 18, 2019 at 07:18:28PM +0300, Andrey Ryabinin wrote:
> On 7/18/19 5:14 PM, Arnd Bergmann wrote:

> > asan-stack mode still uses dangerously large kernel stacks of
> > tens of kilobytes in some drivers, and it does not seem that anyone
> > is working on the clang bug.

> > -	default !(CLANG_VERSION < 90000)
> > +	default !(CLANG_VERSION < 100000)

> Wouldn't be better to make this thing for any clang version? And only when the bug is
> finally fixed, specify the clang version which can enable this safely.

Especially if nobody is currently working on it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] kasan: push back KASAN_STACK detection to clang-10

[Nick Desaulniers]

On Thu, Jul 18, 2019 at 9:23 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, Jul 18, 2019 at 07:18:28PM +0300, Andrey Ryabinin wrote:
> > On 7/18/19 5:14 PM, Arnd Bergmann wrote:
>
> > > asan-stack mode still uses dangerously large kernel stacks of
> > > tens of kilobytes in some drivers, and it does not seem that anyone
> > > is working on the clang bug.
>
> > > -   default !(CLANG_VERSION < 90000)
> > > +   default !(CLANG_VERSION < 100000)
>
> > Wouldn't be better to make this thing for any clang version? And only when the bug is
> > finally fixed, specify the clang version which can enable this safely.
>
> Especially if nobody is currently working on it.

I agree.
-- 
Thanks,
~Nick Desaulniers