| Message ID | 20170302163834.2273519-2-arnd@arndb.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 03/02/2017 07:38 PM, Arnd Bergmann wrote: > When CONFIG_KASAN is set, we can run into some code that uses incredible > amounts of kernel stack: > > drivers/staging/dgnc/dgnc_neo.c:1056:1: error: the frame size of 11112 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] > drivers/media/i2c/cx25840/cx25840-core.c:4960:1: error: the frame size of 94000 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] > drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] > > This happens when a sanitizer uses stack memory each time an inline function > gets called. This introduces a new annotation for those functions to make > them either 'inline' or 'noinline' dependning on the CONFIG_KASAN symbol. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > include/linux/compiler.h | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/include/linux/compiler.h b/include/linux/compiler.h > index f8110051188f..56b90897a459 100644 > --- a/include/linux/compiler.h > +++ b/include/linux/compiler.h > @@ -416,6 +416,17 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s > */ > #define noinline_for_stack noinline > > +/* > + * CONFIG_KASAN can lead to extreme stack usage with certain patterns when > + * one function gets inlined many times and each instance requires a stack > + * ckeck. > + */ > +#ifdef CONFIG_KASAN > +#define noinline_for_kasan noinline __maybe_unused noinline_iff_kasan might be a better name. noinline_for_kasan gives the impression that we always noinline function for the sake of kasan, while noinline_iff_kasan clearly indicates that function is noinline only if kasan is used. > +#else > +#define noinline_for_kasan inline > +#endif > + > #ifndef __always_inline > #define __always_inline inline > #endif >
On Fri, Mar 3, 2017 at 2:50 PM, Andrey Ryabinin <aryabinin@virtuozzo.com> wrote: > > > On 03/02/2017 07:38 PM, Arnd Bergmann wrote: >> When CONFIG_KASAN is set, we can run into some code that uses incredible >> amounts of kernel stack: >> >> drivers/staging/dgnc/dgnc_neo.c:1056:1: error: the frame size of 11112 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] >> drivers/media/i2c/cx25840/cx25840-core.c:4960:1: error: the frame size of 94000 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] >> drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] >> >> This happens when a sanitizer uses stack memory each time an inline function >> gets called. This introduces a new annotation for those functions to make >> them either 'inline' or 'noinline' dependning on the CONFIG_KASAN symbol. >> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de> >> --- >> include/linux/compiler.h | 11 +++++++++++ >> 1 file changed, 11 insertions(+) >> >> diff --git a/include/linux/compiler.h b/include/linux/compiler.h >> index f8110051188f..56b90897a459 100644 >> --- a/include/linux/compiler.h >> +++ b/include/linux/compiler.h >> @@ -416,6 +416,17 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s >> */ >> #define noinline_for_stack noinline >> >> +/* >> + * CONFIG_KASAN can lead to extreme stack usage with certain patterns when >> + * one function gets inlined many times and each instance requires a stack >> + * ckeck. >> + */ >> +#ifdef CONFIG_KASAN >> +#define noinline_for_kasan noinline __maybe_unused > > > noinline_iff_kasan might be a better name. noinline_for_kasan gives the impression > that we always noinline function for the sake of kasan, while noinline_iff_kasan > clearly indicates that function is noinline only if kasan is used. FWIW we may be facing the same problem with other compiler-based tools, e.g. KMSAN (which isn't there yet). So it might be better to choose a macro name that doesn't use the name "KASAN". E.g. noinline_iff_memtool (or noinline_iff_memory_tool if that's not too long). WDYT? >> +#else >> +#define noinline_for_kasan inline >> +#endif >> + >> #ifndef __always_inline >> #define __always_inline inline >> #endif >> > > -- > You received this message because you are subscribed to the Google Groups "kasan-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com. > To post to this group, send email to kasan-dev@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/7e7a62de-3b79-6044-72fa-4ade418953d1%40virtuozzo.com. > For more options, visit https://groups.google.com/d/optout.
On Fri, Mar 3, 2017 at 2:55 PM, Alexander Potapenko <glider@google.com> wrote: > On Fri, Mar 3, 2017 at 2:50 PM, Andrey Ryabinin <aryabinin@virtuozzo.com> wrote: >>> @@ -416,6 +416,17 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s >>> */ >>> #define noinline_for_stack noinline >>> >>> +/* >>> + * CONFIG_KASAN can lead to extreme stack usage with certain patterns when >>> + * one function gets inlined many times and each instance requires a stack >>> + * ckeck. >>> + */ >>> +#ifdef CONFIG_KASAN >>> +#define noinline_for_kasan noinline __maybe_unused >> >> >> noinline_iff_kasan might be a better name. noinline_for_kasan gives the impression >> that we always noinline function for the sake of kasan, while noinline_iff_kasan >> clearly indicates that function is noinline only if kasan is used. Fine with me. I actually tried to come up with a name that implies that the symbol is actually "inline" (or even __always_inline_ without KASAN, but couldn't think of any good name for it. > FWIW we may be facing the same problem with other compiler-based > tools, e.g. KMSAN (which isn't there yet). > So it might be better to choose a macro name that doesn't use the name "KASAN". > E.g. noinline_iff_memtool (or noinline_iff_memory_tool if that's not too long). > WDYT? Would KMSAN also force local variables to be non-overlapping the way that asan-stack=1 and -fsanitize-address-use-after-scope do? As I understood it, KMSAN would add extra code for maintaining the uninit bits, but in an example like this int f(int *); static inline __attribute__((always_inline)) int g(void) { int i; f(&i); return i; } int f(void) { return g()+g()+g()+g(); } each of the four copies of 'i' could have the same location on the stack and get marked uninitialized again before calling f(). We only need noinline_for_kasan (whatever we end up calling that) for compiler features that force each instance of 'i' to have its own stack redzone. Arnd
On Fri, Mar 3, 2017 at 3:30 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Fri, Mar 3, 2017 at 2:55 PM, Alexander Potapenko <glider@google.com> wrote: >> On Fri, Mar 3, 2017 at 2:50 PM, Andrey Ryabinin <aryabinin@virtuozzo.com> wrote: > >>>> @@ -416,6 +416,17 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s >>>> */ >>>> #define noinline_for_stack noinline >>>> >>>> +/* >>>> + * CONFIG_KASAN can lead to extreme stack usage with certain patterns when >>>> + * one function gets inlined many times and each instance requires a stack >>>> + * ckeck. >>>> + */ >>>> +#ifdef CONFIG_KASAN >>>> +#define noinline_for_kasan noinline __maybe_unused >>> >>> >>> noinline_iff_kasan might be a better name. noinline_for_kasan gives the impression >>> that we always noinline function for the sake of kasan, while noinline_iff_kasan >>> clearly indicates that function is noinline only if kasan is used. > > Fine with me. I actually tried to come up with a name that implies that the > symbol is actually "inline" (or even __always_inline_ without KASAN, but > couldn't think of any good name for it. > >> FWIW we may be facing the same problem with other compiler-based >> tools, e.g. KMSAN (which isn't there yet). >> So it might be better to choose a macro name that doesn't use the name "KASAN". >> E.g. noinline_iff_memtool (or noinline_iff_memory_tool if that's not too long). >> WDYT? > > Would KMSAN also force local variables to be non-overlapping the way that > asan-stack=1 and -fsanitize-address-use-after-scope do? As I understood it, > KMSAN would add extra code for maintaining the uninit bits, but in an example > like this The thing is that KMSAN (and other tools that insert heavyweight instrumentation) may cause heavy register spilling which will also blow up the stack frames. > int f(int *); > static inline __attribute__((always_inline)) int g(void) > { > int i; > f(&i); > return i; > } > int f(void) > { > return g()+g()+g()+g(); > } > > each of the four copies of 'i' could have the same location on the stack > and get marked uninitialized again before calling f(). We only need > noinline_for_kasan (whatever we end up calling that) for compiler > features that force each instance of 'i' to have its own stack redzone. > > Arnd
On Fri, Mar 3, 2017 at 3:33 PM, Alexander Potapenko <glider@google.com> wrote: > On Fri, Mar 3, 2017 at 3:30 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> On Fri, Mar 3, 2017 at 2:55 PM, Alexander Potapenko <glider@google.com> wrote: >> >> Would KMSAN also force local variables to be non-overlapping the way that >> asan-stack=1 and -fsanitize-address-use-after-scope do? As I understood it, >> KMSAN would add extra code for maintaining the uninit bits, but in an example >> like this > The thing is that KMSAN (and other tools that insert heavyweight > instrumentation) may cause heavy register spilling which will also > blow up the stack frames. In that case, I would expect a mostly distinct set of functions to have large stack frames with KMSAN, compared to the ones that need noinline_for_kasan. In most cases I patched, the called inline function is actually trivial, but invoked many times from the same caller. Arnd
From: Andrey Ryabinin > Sent: 03 March 2017 13:50 ... > noinline_iff_kasan might be a better name. noinline_for_kasan gives the impression > that we always noinline function for the sake of kasan, while noinline_iff_kasan > clearly indicates that function is noinline only if kasan is used. noinline_if_stackbloat David
diff --git a/include/linux/compiler.h b/include/linux/compiler.h index f8110051188f..56b90897a459 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -416,6 +416,17 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s */ #define noinline_for_stack noinline +/* + * CONFIG_KASAN can lead to extreme stack usage with certain patterns when + * one function gets inlined many times and each instance requires a stack + * ckeck. + */ +#ifdef CONFIG_KASAN +#define noinline_for_kasan noinline __maybe_unused +#else +#define noinline_for_kasan inline +#endif + #ifndef __always_inline #define __always_inline inline #endif
When CONFIG_KASAN is set, we can run into some code that uses incredible amounts of kernel stack: drivers/staging/dgnc/dgnc_neo.c:1056:1: error: the frame size of 11112 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] drivers/media/i2c/cx25840/cx25840-core.c:4960:1: error: the frame size of 94000 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] This happens when a sanitizer uses stack memory each time an inline function gets called. This introduces a new annotation for those functions to make them either 'inline' or 'noinline' dependning on the CONFIG_KASAN symbol. Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- include/linux/compiler.h | 11 +++++++++++ 1 file changed, 11 insertions(+)