linux-kernel - Re: mm/memcontrol.c:5364:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20171214181608.GA2476@cmpxchg.org>
Date:   Thu, 14 Dec 2017 13:16:08 -0500
From:   Johannes Weiner <hannes@...xchg.org>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Paul Menzel <pmenzel+linux-cgroups@...gen.mpg.de>,
        Vladimir Davydov <vdavydov.dev@...il.com>,
        cgroups@...r.kernel.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, it+linux-cgroups@...gen.mpg.de
Subject: Re: mm/memcontrol.c:5364:1: warning: the frame size of 1032 bytes is
 larger than 1024 bytes [-Wframe-larger-than=]

On Thu, Dec 14, 2017 at 10:19:17AM +0100, Michal Hocko wrote:
> On Thu 14-12-17 07:49:29, Paul Menzel wrote:
> > I enabled the undefined behavior sanitizer, and built Linus’ master branch
> > under Ubuntu 17.10 with gcc (Ubuntu 7.2.0-8ubuntu3) 7.2.0.
> > 
> > ```
> > $ grep UBSAN /boot/config-4.15.0-rc3+
> > CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y
> > # CONFIG_ARCH_WANTS_UBSAN_NO_NULL is not set
> > CONFIG_UBSAN=y
> > CONFIG_UBSAN_SANITIZE_ALL=y
> > # CONFIG_UBSAN_ALIGNMENT is not set
> > CONFIG_UBSAN_NULL=y

> But this depends on the configuration because NR_VM_EVENT_ITEMS enables
> some counters depending on the config. The stack is really large but
> this is a function which is called from a shallow context wrt. stack so
> we should fit into a single page. One way we could do, though, is to
> make those large arrays static and use a internal lock around them.
> Something like the following. What do you think Johannes?

As you said, this is a very shallow stack. Why introduce a global lock
to save memory, when we have a statically allocated 16k kernel stack
which we know is plenty for that call chain? It introduces a potential
bottleneck for nothing in return.