From: Joe Perches <joe@perches.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: kasan-dev <kasan-dev@googlegroups.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Networking <netdev@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-media@vger.kernel.org,
linux-wireless <linux-wireless@vger.kernel.org>,
kernel-build-reports@lists.linaro.org,
"David S . Miller" <davem@davemloft.net>
Subject: Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN
Date: Thu, 02 Mar 2017 14:40:28 -0800 [thread overview]
Message-ID: <1488494428.2179.23.camel@perches.com> (raw)
In-Reply-To: <CAK8P3a1gW9UqMKD2ijzxMH4rv1zAji0GUoz+bLY_oi0yvLU1cw@mail.gmail.com>
On Thu, 2017-03-02 at 23:22 +0100, Arnd Bergmann wrote:
> On Thu, Mar 2, 2017 at 6:46 PM, Joe Perches <joe@perches.com> 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.
WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: kasan-dev <kasan-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>,
Andrey Ryabinin
<aryabinin-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>,
Alexander Potapenko
<glider-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Dmitry Vyukov <dvyukov-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Networking <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-wireless
<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
kernel-build-reports-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
"David S . Miller"
<davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Subject: Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN
Date: Thu, 02 Mar 2017 14:40:28 -0800 [thread overview]
Message-ID: <1488494428.2179.23.camel@perches.com> (raw)
In-Reply-To: <CAK8P3a1gW9UqMKD2ijzxMH4rv1zAji0GUoz+bLY_oi0yvLU1cw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, 2017-03-02 at 23:22 +0100, Arnd Bergmann wrote:
> On Thu, Mar 2, 2017 at 6:46 PM, Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org> 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.
next prev parent reply other threads:[~2017-03-02 22:44 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-02 16:38 [PATCH 00/26] bring back stack frame warning with KASAN Arnd Bergmann
2017-03-02 16:38 ` Arnd Bergmann
2017-03-02 16:38 ` [PATCH 01/26] compiler: introduce noinline_for_kasan annotation Arnd Bergmann
2017-03-03 13:50 ` Andrey Ryabinin
2017-03-03 13:55 ` Alexander Potapenko
2017-03-03 13:55 ` Alexander Potapenko
2017-03-03 14:30 ` Arnd Bergmann
2017-03-03 14:33 ` Alexander Potapenko
2017-03-03 14:33 ` Alexander Potapenko
2017-03-03 14:51 ` Arnd Bergmann
2017-03-03 16:34 ` David Laight
2017-03-02 16:38 ` [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE Arnd Bergmann
2017-03-02 16:51 ` Christian Borntraeger
2017-03-02 17:55 ` Arnd Bergmann
2017-03-02 19:00 ` Christian Borntraeger
2017-03-02 21:45 ` Arnd Bergmann
2017-03-03 8:26 ` Christian Borntraeger
2017-03-03 8:26 ` Christian Borntraeger
2017-03-03 9:54 ` Arnd Bergmann
2017-03-03 9:54 ` Arnd Bergmann
2017-03-03 14:49 ` Peter Zijlstra
2017-03-03 14:49 ` Peter Zijlstra
2017-03-03 14:57 ` Peter Zijlstra
2017-03-02 16:38 ` [PATCH 03/26] typecheck.h: avoid local variables in typecheck() macro Arnd Bergmann
2017-03-02 16:38 ` [PATCH 04/26] tty: kbd: reduce stack size with KASAN Arnd Bergmann
2017-03-02 16:38 ` [PATCH 05/26] netlink: mark nla_put_{u8,u16,u32} noinline_for_kasan Arnd Bergmann
2017-03-02 16:38 ` [PATCH 06/26] rocker: mark rocker_tlv_put_* functions as noinline_for_kasan Arnd Bergmann
2017-03-02 16:38 ` [PATCH 07/26] brcmsmac: reduce stack size with KASAN Arnd Bergmann
2017-03-06 9:16 ` Arend Van Spriel
2017-03-06 10:38 ` Arnd Bergmann
2017-03-06 11:02 ` Arend Van Spriel
2017-03-06 11:16 ` Arnd Bergmann
2017-03-06 11:18 ` Arnd Bergmann
2017-03-02 16:38 ` [PATCH 08/26] brcmsmac: make some local variables 'static const' to reduce stack size Arnd Bergmann
2017-03-06 9:30 ` Arend Van Spriel
2017-03-06 9:30 ` Arend Van Spriel
2017-03-06 16:19 ` Kalle Valo
2017-03-06 21:34 ` Arnd Bergmann
2017-03-06 21:34 ` Arnd Bergmann
2017-03-07 9:44 ` Kalle Valo
2017-03-07 9:55 ` Arend Van Spriel
2017-03-02 16:38 ` [PATCH 09/26] brcmsmac: split up wlc_phy_workarounds_nphy Arnd Bergmann
2017-03-06 9:31 ` Arend Van Spriel
2017-03-02 16:38 ` [PATCH 10/26] brcmsmac: reindent split functions Arnd Bergmann
2017-03-06 9:33 ` Arend Van Spriel
2017-03-06 16:24 ` Kalle Valo
2017-03-02 16:38 ` [PATCH 11/26] rtlwifi: reduce stack usage for KASAN Arnd Bergmann
2017-03-02 16:38 ` [PATCH 12/26] wl3501_cs: reduce stack size " Arnd Bergmann
2017-03-02 16:38 ` [PATCH 13/26] rtl8180: " Arnd Bergmann
2017-03-02 16:38 ` Arnd Bergmann
2017-03-02 16:38 ` [PATCH 14/26] [media] dvb-frontends: reduce stack size in i2c access Arnd Bergmann
2017-03-02 16:38 ` [PATCH 15/26] [media] tuners: i2c: reduce stack usage for tuner_i2c_xfer_* Arnd Bergmann
2017-03-02 16:38 ` [PATCH 16/26] [media] i2c: adv7604: mark register access as noinline_for_kasan Arnd Bergmann
2017-03-02 16:38 ` [PATCH 17/26] [media] i2c: ks0127: reduce stack frame size for KASAN Arnd Bergmann
2017-03-02 16:38 ` [PATCH 18/26] [media] i2c: cx25840: avoid stack overflow with KASAN Arnd Bergmann
2017-03-02 16:38 ` [PATCH 19/26] [media] r820t: mark register functions as noinline_for_kasan Arnd Bergmann
2017-03-02 16:38 ` [PATCH 20/26] [media] em28xx: split up em28xx_dvb_init to reduce stack size Arnd Bergmann
2017-04-17 17:07 ` Mauro Carvalho Chehab
2017-03-02 16:38 ` [PATCH 21/26] drm/bridge: ps8622: reduce stack size for KASAN Arnd Bergmann
2017-03-02 16:38 ` [PATCH 22/26] drm/i915/gvt: don't overflow the kernel stack with KASAN Arnd Bergmann
2017-03-02 16:38 ` [PATCH 23/26] mtd: cfi: reduce stack size " Arnd Bergmann
2017-03-02 16:38 ` Arnd Bergmann
2017-03-02 16:38 ` [PATCH 24/26] ocfs2: " Arnd Bergmann
2017-03-02 17:46 ` Joe Perches
2017-03-02 22:22 ` Arnd Bergmann
2017-03-02 22:40 ` Joe Perches [this message]
2017-03-02 22:40 ` Joe Perches
2017-03-02 22:59 ` Arnd Bergmann
2017-03-02 23:58 ` Joe Perches
2017-03-02 16:38 ` [PATCH 25/26] isdn: eicon: mark divascapi incompatible with kasan Arnd Bergmann
2017-03-03 14:20 ` Andrey Ryabinin
2017-03-03 14:54 ` Arnd Bergmann
2017-03-03 15:22 ` Andrey Ryabinin
2017-03-03 15:37 ` Arnd Bergmann
2017-03-02 16:38 ` [PATCH 26/26] kasan: rework Kconfig settings Arnd Bergmann
2017-03-03 14:51 ` Andrey Ryabinin
2017-03-03 15:03 ` Arnd Bergmann
2017-03-03 12:25 ` [PATCH 00/26] bring back stack frame warning with KASAN Alexander Potapenko
2017-03-03 12:25 ` Alexander Potapenko
2017-03-03 12:54 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1488494428.2179.23.camel@perches.com \
--to=joe@perches.com \
--cc=arnd@arndb.de \
--cc=aryabinin@virtuozzo.com \
--cc=davem@davemloft.net \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=kernel-build-reports@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.