Date:   Mon, 5 Nov 2018 14:15:35 +0100
From:   Martin Schwidefsky <schwidefsky@...ibm.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        dan.carpenter@...cle.com, adilger.kernel@...ger.ca,
        yamada.masahiro@...ionext.com, michal.lkml@...kovi.net,
        rostedt@...dmis.org, mchehab+samsung@...nel.org, olof@...m.net,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
        David Miller <davem@...emloft.net>,
        Kees Cook <keescook@...omium.org>, tglx@...utronix.de,
        Ingo Molnar <mingo@...nel.org>, paullawrence@...gle.com,
        sandipan@...ux.vnet.ibm.com, andreyknvl@...gle.com,
        David Woodhouse <dwmw2@...radead.org>, will.deacon@....com,
        Philippe Ombredanne <pombredanne@...b.com>,
        paul.burton@...s.com, rientjes@...gle.com, w@....eu,
        msebor@...il.com, Chris Li <sparse@...isli.org>,
        Jonathan Corbet <corbet@....net>,
        "Theodore Ts'o" <tytso@....edu>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Rasmus Villemoes <linux@...musvillemoes.dk>, joe@...ches.com,
        Arnd Bergmann <arnd@...db.de>, asmadeus@...ewreck.org,
        stefan@...er.ch, luc.vanoostenryck@...il.com,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        linux-doc@...r.kernel.org, linux-ext4@...r.kernel.org,
        linux-sparse@...r.kernel.org, linux-kbuild@...r.kernel.org
Subject: Re: [GIT PULL] Compiler Attributes for v4.20-rc1

On Mon, 5 Nov 2018 07:02:56 +0100
Martin Schwidefsky <schwidefsky@...ibm.com> wrote:

> On Fri, 2 Nov 2018 09:09:32 -0700
> Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> 
> > On Fri, Nov 2, 2018 at 2:43 AM Andrey Ryabinin <aryabinin@...tuozzo.com> wrote:  
> > >
> > > You're right, version checks shouldn't matter here. But __no_sanitize_address_or_inline
> > > shouldn't have been added in the first place, because we already have almost the same
> > >__no_kasan_or_inline:    
> > 
> > Ahh, very good.
> > 
> > Vasily, Martin - since __no_sanitize_address_or_inline was added just
> > for s390, would you mind replacing it with __no_kasan_or_inline
> > instead, and testing that in whatever failed before?
> > 
> > Then we can just remove that unnecessary symbol #define entirely..  
> 
> Ok, will do.
 
Follow-up question: the __no_sanitize_address_or_inline define has the 'notrace'
option that is missing for __no_kasan_or_inline. We need that option for
__load_psw_mask, if we do the replacement all users of __no_kasan_or_inline
would get the option as well. This affects __read_once_size_nocheck and
read_word_at_a_time. Do these function have to be traceable ?

This patch would work for me:
--
>From 4aaa09fe4b54e930edabac86606dee979b12647c Mon Sep 17 00:00:00 2001
From: Martin Schwidefsky <schwidefsky@...ibm.com>
Date: Mon, 5 Nov 2018 07:36:28 +0100
Subject: [PATCH] compiler: remove __no_sanitize_address_or_inline again

The __no_sanitize_address_or_inline and __no_kasan_or_inline defines
are almost identical. The only difference is that __no_kasan_or_inline
does not have the 'notrace' attribute.

To be able to replace __no_sanitize_address_or_inline with the older
definition, add 'notrace' to __no_kasan_or_inline and change to two
users of __no_sanitize_address_or_inline in the s390 code.

The 'notrace' option is necessary for e.g. the __load_psw_mask function
in arch/s390/include/asm/processor.h. Without the option it is possible
to trace __load_psw_mask which leads to kernel stack overflow.

Signed-off-by: Martin Schwidefsky <schwidefsky@...ibm.com>
---
 arch/s390/include/asm/processor.h |  4 ++--
 include/linux/compiler-gcc.h      | 12 ------------
 include/linux/compiler.h          |  2 +-
 3 files changed, 3 insertions(+), 15 deletions(-)

diff --git a/arch/s390/include/asm/processor.h b/arch/s390/include/asm/processor.h
index 302795c47c06..81038ab357ce 100644
--- a/arch/s390/include/asm/processor.h
+++ b/arch/s390/include/asm/processor.h
@@ -236,7 +236,7 @@ static inline unsigned long current_stack_pointer(void)
 	return sp;
 }
 
-static __no_sanitize_address_or_inline unsigned short stap(void)
+static __no_kasan_or_inline unsigned short stap(void)
 {
 	unsigned short cpu_address;
 
@@ -330,7 +330,7 @@ static inline void __load_psw(psw_t psw)
  * Set PSW mask to specified value, while leaving the
  * PSW addr pointing to the next instruction.
  */
-static __no_sanitize_address_or_inline void __load_psw_mask(unsigned long mask)
+static __no_kasan_or_inline void __load_psw_mask(unsigned long mask)
 {
 	unsigned long addr;
 	psw_t psw;
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index c0f5db3a9621..2010493e1040 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -143,18 +143,6 @@
 #define KASAN_ABI_VERSION 3
 #endif
 
-/*
- * Because __no_sanitize_address conflicts with inlining:
- *   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
- * we do one or the other. 
- */
-#ifdef CONFIG_KASAN
-#define __no_sanitize_address_or_inline					\
-	__no_sanitize_address __maybe_unused notrace
-#else
-#define __no_sanitize_address_or_inline inline
-#endif
-
 #if GCC_VERSION >= 50100
 #define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1
 #endif
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 18c80cfa4fc4..06396c1cf127 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -189,7 +189,7 @@ void __read_once_size(const volatile void *p, void *res, int size)
  * 	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
  * '__maybe_unused' allows us to avoid defined-but-not-used warnings.
  */
-# define __no_kasan_or_inline __no_sanitize_address __maybe_unused
+# define __no_kasan_or_inline __no_sanitize_address notrace __maybe_unused
 #else
 # define __no_kasan_or_inline __always_inline
 #endif
-- 
2.16.4
-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Powered by blists - more mailing lists