Return-path: Received: from mail-ot0-f194.google.com ([74.125.82.194]:35647 "EHLO mail-ot0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751593AbdCCOwL (ORCPT ); Fri, 3 Mar 2017 09:52:11 -0500 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: Arnd Bergmann Date: Fri, 3 Mar 2017 15:51:41 +0100 Message-ID: (sfid-20170303_161100_833566_52B0660E) Subject: Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation To: Alexander Potapenko 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:33 PM, Alexander Potapenko wrote: > On Fri, Mar 3, 2017 at 3:30 PM, Arnd Bergmann wrote: >> On Fri, Mar 3, 2017 at 2:55 PM, Alexander Potapenko 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