linux-kernel - Re: ipv4/tcp.c:4234:1: error: the frame size of 1152 bytes is larger than 1024 bytes [-Werror=frame-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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 8 Sep 2021 18:56:25 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Eric Dumazet <edumazet@...gle.com>,
        Thorsten Glaser <t.glaser@...ent.de>,
        Naresh Kamboju <naresh.kamboju@...aro.org>,
        Mathias Nyman <mathias.nyman@...el.com>,
        Johannes Berg <johannes@...solutions.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Shuah Khan <skhan@...uxfoundation.org>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        Ariel Elior <aelior@...vell.com>,
        GR-everest-linux-l2@...vell.com, Wei Liu <wei.liu@...nel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        open list <linux-kernel@...r.kernel.org>,
        Netdev <netdev@...r.kernel.org>, lkft-triage@...ts.linaro.org,
        Arnd Bergmann <arnd@...db.de>,
        "David S. Miller" <davem@...emloft.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>
Subject: Re: ipv4/tcp.c:4234:1: error: the frame size of 1152 bytes is larger
 than 1024 bytes [-Werror=frame-larger-than=]

On Wed, Sep 8, 2021 at 5:49 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Wed, Sep 8, 2021 at 7:50 AM Eric Dumazet <edumazet@...gle.com> wrote:
> In the past I've seen at least two patterns
>
>  (a) not merging stack slots at all
>
>  (b) some odd "pattern allocator" problems, where I think gcc ended up
> re-using previous stack slots if they were the right size, but failing
> when previous allocations were fragmented
>
> that (a) thing is what -fconserve-stack is all about, and we also used
> to have (iirc) -fno-defer-pop to avoid having function call argument
> stacks stick around.

CONFIG_KASAN_STACK leads to (a), and this has been the source of
long discussions about whether to turn it off altogether, the current state
being that it's disabled for CONFIG_COMPILE_TEST on clang because
this can explode the stack usage even further when it starts spilling
registers.

gcc also runs into this problem, but at least newer versions at not nearly
as bad as they used to be in the past.

       Arnd