Return-path: Received: from mail-qk0-f174.google.com ([209.85.220.174]:34667 "EHLO mail-qk0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752123AbdCCOfO (ORCPT ); Fri, 3 Mar 2017 09:35:14 -0500 Received: by mail-qk0-f174.google.com with SMTP id s186so177747934qkb.1 for ; Fri, 03 Mar 2017 06:33:17 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20170302163834.2273519-1-arnd@arndb.de> <20170302163834.2273519-2-arnd@arndb.de> <7e7a62de-3b79-6044-72fa-4ade418953d1@virtuozzo.com> From: Alexander Potapenko Date: Fri, 3 Mar 2017 15:33:16 +0100 Message-ID: (sfid-20170303_153602_680402_2409CF8B) Subject: Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation To: Arnd Bergmann Cc: Andrey Ryabinin , kasan-dev , Dmitry Vyukov , Networking , LKML , linux-media@vger.kernel.org, linux-wireless , kernel-build-reports@lists.linaro.org, "David S . Miller" Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Fri, Mar 3, 2017 at 3:30 PM, Arnd Bergmann wrote: > On Fri, Mar 3, 2017 at 2:55 PM, Alexander Potapenko w= rote: >> On Fri, Mar 3, 2017 at 2:50 PM, Andrey Ryabinin wrote: > >>>> @@ -416,6 +416,17 @@ static __always_inline void __write_once_size(vol= atile 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 th= e 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 t= he > 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=3D1 and -fsanitize-address-use-after-scope do? As I understood= it, > KMSAN would add extra code for maintaining the uninit bits, but in an exa= mple > 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 --=20 Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Matthew Scott Sucherman, Paul Terence Manicle Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg