Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   David Laight <David.Laight@ACULAB.COM>
To:     'Wei Liu' <wei.liu@kernel.org>
CC:     Linus Torvalds <torvalds@linux-foundation.org>,
        Naresh Kamboju <naresh.kamboju@linaro.org>,
        Mathias Nyman <mathias.nyman@intel.com>,
        Johannes Berg <johannes@sipsolutions.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Shuah Khan <skhan@linuxfoundation.org>,
        Brendan Higgins <brendanhiggins@google.com>,
        Ariel Elior <aelior@marvell.com>,
        "GR-everest-linux-l2@marvell.com" <GR-everest-linux-l2@marvell.com>,
        "Linux ARM" <linux-arm-kernel@lists.infradead.org>,
        open list <linux-kernel@vger.kernel.org>,
        Netdev <netdev@vger.kernel.org>,
        "lkft-triage@lists.linaro.org" <lkft-triage@lists.linaro.org>,
        Arnd Bergmann <arnd@arndb.de>,
        "David S. Miller" <davem@davemloft.net>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Nathan Chancellor <nathan@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Alexei Starovoitov <ast@kernel.org>,
        Eric Dumazet <edumazet@google.com>
Subject: RE: ipv4/tcp.c:4234:1: error: the frame size of 1152 bytes is larger
 than 1024 bytes [-Werror=frame-larger-than=]
Thread-Topic: ipv4/tcp.c:4234:1: error: the frame size of 1152 bytes is larger
 than 1024 bytes [-Werror=frame-larger-than=]
Thread-Index: AQHXpJjLHdBfxh/omUuYsxLT8U4Q1auaODzA///43ICAABV5QA==
Date:   Wed, 8 Sep 2021 16:05:12 +0000
Message-ID: <e8d16a01fd3144f1b57faae59f991579@AcuMS.aculab.com>
References: <CA+G9fYtFvJdtBknaDKR54HHMf4XsXKD4UD3qXkQ1KhgY19n3tw@mail.gmail.com>
 <CAHk-=wisUqoX5Njrnnpp0pDx+bxSAJdPxfgEUv82tZkvUqoN1w@mail.gmail.com>
 <CAHk-=whF9F89vsfH8E9TGc0tZA-yhzi2Di8wOtquNB5vRkFX5w@mail.gmail.com>
 <20210908100304.oknxj4v436sbg3nb@liuwe-devbox-debian-v2>
 <46be667d057f413aac7871ebe784e274@AcuMS.aculab.com>
 <20210908152351.asln63jxk43xffib@liuwe-devbox-debian-v2>
In-Reply-To: <20210908152351.asln63jxk43xffib@liuwe-devbox-debian-v2>
Accept-Language: en-GB, en-US
MIME-Version: 1.0
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Precedence: bulk

From: Wei Liu
> Sent: 08 September 2021 16:24
> 
> On Wed, Sep 08, 2021 at 02:51:21PM +0000, David Laight wrote:
> > From: Wei Liu
> > > Sent: 08 September 2021 11:03
> > ...
> > > However calling into the allocator from that IPI path seems very heavy
> > > weight. I will discuss with fellow engineers on how to fix it properly.
> >
> > Isn't the IPI code something that is likely to get called
> > when a lot of stack has already been used?
> >
> > So you really shouldn't be using much stack at all??
> 
> I don't follow your questions. I don't dispute there is a problem. I
> just think calling into the allocator is not a good idea in that
> particular piece of code we need to fix.
> 
> Hopefully we can come up with a solution to remove need for a cpumask in
> that code -- discussion is on-going.

I'm pretty sure the IPI interrupt is high priority so can
nest with another interrupt.
(You certainly want it to be that way.)

So the kernel may already be running on the interrupt stack.
If the interrupted ISR code has used a lot of stack then
there may not be as much left as you might expect.

Many years ago (nearly 40!) I wrote something that did static
stack depth analysis for an embedded system.
Since there were no (interesting) indirect calls an no recursion
it wasn't completely impossible.
What it showed was that the deepest stack use was in error
trace paths that probably never happened.
I suspect the same is true for Linux - the deepest points
will be inside printk() in obscure error paths.
Get an IPI while in a printk() from deep inside an ISR
and you may not have the amount of stack you expect.

It might be possible to use the clang 'control flow integrity'
information to determine the actual maximum stack use even
for indirectly called functions.
I suspect that would be an eye-opener....

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)