From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751334AbdCBWsC (ORCPT ); Thu, 2 Mar 2017 17:48:02 -0500 Received: from smtprelay0243.hostedemail.com ([216.40.44.243]:39538 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751114AbdCBWsB (ORCPT ); Thu, 2 Mar 2017 17:48:01 -0500 X-Session-Marker: 6A6F6540706572636865732E636F6D X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,joe@perches.com,:::::::::::::::::::::,RULES_HIT:41:355:379:541:599:800:960:973:988:989:1260:1277:1311:1313:1314:1345:1359:1373:1437:1515:1516:1518:1534:1542:1593:1594:1711:1730:1747:1777:1792:2198:2199:2393:2553:2559:2562:2828:3138:3139:3140:3141:3142:3355:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:4250:4321:5007:6119:7903:7974:8603:9713:10004:10400:10848:11026:11232:11473:11658:11914:12043:12296:12438:12740:12760:12895:13146:13161:13229:13230:13439:14181:14659:14721:14877:21080:21325:21434:30012:30034:30054:30060:30070:30079:30090:30091,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:1,LUA_SUMMARY:none X-HE-Tag: roof92_3e92fefac7e3b X-Filterd-Recvd-Size: 4015 Message-ID: <1488494428.2179.23.camel@perches.com> Subject: Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN From: Joe Perches To: Arnd Bergmann Cc: kasan-dev , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Networking , Linux Kernel Mailing List , linux-media@vger.kernel.org, linux-wireless , kernel-build-reports@lists.linaro.org, "David S . Miller" Date: Thu, 02 Mar 2017 14:40:28 -0800 In-Reply-To: References: <20170302163834.2273519-1-arnd@arndb.de> <20170302163834.2273519-25-arnd@arndb.de> <1488476770.2179.6.camel@perches.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.22.3-0ubuntu0.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2017-03-02 at 23:22 +0100, Arnd Bergmann wrote: > On Thu, Mar 2, 2017 at 6:46 PM, Joe Perches wrote: > > On Thu, 2017-03-02 at 17:38 +0100, Arnd Bergmann wrote: > > > The internal logging infrastructure in ocfs2 causes special warning code to be > > > used with KASAN, which produces rather large stack frames: > > > fs/ocfs2/super.c: In function 'ocfs2_fill_super': > > > fs/ocfs2/super.c:1219:1: error: the frame size of 3264 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] > > > > At least by default it doesn't seem to. > > > > gcc 6.2 allyesconfig, CONFIG_KASAN=y > > with either CONFIG_KASAN_INLINE or CONFIG_KASAN_OUTLINE > > > > gcc doesn't emit a stack warning > > The warning is disabled until patch 26/26. which picks the 3072 default. > The 3264 number was with gcc-7, which is worse than gcc-6 since it enables > an extra check. > > > > By simply passing the mask by value instead of reference, we can avoid the > > > problem completely. > > > > Any idea why that's so? > > With KASAN, every time we inline the function, the compiler has to allocate > space for another copy of the variable plus a redzone to detect whether > passing it by reference into another function causes an overflow at runtime. These logging functions aren't inlined. You're referring to the stack frame? > > > On 64-bit architectures, this is also more efficient, > > > > Efficient true, but the same overall stack no? > > Here is what I see with CONFIG_FRAME_WARN=300 and x86_64-linux-gcc-6.3.1: > > before: [] > fs/ocfs2/super.c:1219:1: error: the frame size of 552 bytes is larger > than 300 bytes [-Werror=frame-larger-than=] > > after: > fs/ocfs2/super.c: In function 'ocfs2_fill_super': > fs/ocfs2/super.c:1219:1: error: the frame size of 472 bytes is larger > than 300 bytes [-Werror=frame-larger-than=] > > and with gcc-7.0.1 (including -fsanitize-address-use-after-scope), before: [] > fs/ocfs2/super.c:1219:1: error: the frame size of 3264 bytes is larger > than 300 bytes [-Werror=frame-larger-than=] > > after: > fs/ocfs2/super.c: In function 'ocfs2_fill_super': > fs/ocfs2/super.c:1219:1: error: the frame size of 704 bytes is larger > than 300 bytes [-Werror=frame-larger-than=] Still doesn't make sense to me. None of the logging functions are inlined as they are all EXPORT_SYMBOL. This just changes a pointer to a u64, which is the same size on x86-64 (and is of course larger on x86-32). Perhaps KASAN has the odd behavior and working around KASAN's behavior may not be the proper thing to do. Maybe if CONFIG_KASAN is set, the minimum stack should be increased via THREAD_SIZE_ORDER or some such.