Re: ipv4/tcp.c:4234:1: error: the frame size of 1152 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

[Brendan Higgins]

On Wed, Sep 8, 2021 at 10:16 AM Shuah Khan <sk...@linuxfoundation.org> wrote:
>
> On 9/8/21 11:05 AM, Arnd Bergmann wrote:
> > On Wed, Sep 8, 2021 at 4:12 PM Shuah Khan <sk...@linuxfoundation.org> wrote:
> >> On 9/7/21 5:14 PM, Linus Torvalds wrote:
> >>> The KUNIT macros create all these individually reasonably small
> >>> initialized structures on stack, and when you have more than a small
> >>> handful of them the KUNIT infrastructure just makes the stack space
> >>> explode. Sometimes the compiler will be able to re-use the stack
> >>> slots, but it seems to be an iffy proposition to depend on it - it
> >>> seems to be a combination of luck and various config options.
> >>>
> >>
> >> I have been concerned about these macros creeping in for a while.
> >> I will take a closer look and work with Brendan to come with a plan
> >> to address it.
> >
> > I've previously sent patches to turn off the structleak plugin for
> > any kunit test file to work around this, but only a few of those patches
> > got merged and new files have been added since. It would
> > definitely help to come up with a proper fix, but my structleak-disable
> > hack should be sufficient as a quick fix.
> >
>
> Looks like these are RFC patches and the discussion went cold. Let's pick
> this back up and we can make progress.
>
> https://lore.kernel.org/lkml/CAFd5g45+JqKDqewqz2oZtnph...@mail.gmail.com/

I can try to get the patch reapplying and send it out (I just figured
that Arnd or Kees would want to send it out :-) since it was your
idea).

I definitely agree that in the cases where KUnit is not actually
contributing to blowing the stack - struct leak just thinks it is,
this is fine; however, it sounds like Linus' concerns with KUnit's
macros go deeper than this. Arnd, I think you sketched out a way to
make the KUNIT_* macros take up less space, but after some
investigation we found that it was pretty inflexible.

Ideally test cases should never get big enough for KUNIT_* macros to
be a problem (when they do it is usually an indication that your test
case is trying to do too many things); nevertheless, we are still in
this situation.

I think I will need to dust off some cobwebs out of my brain to
remember why I didn't like the idea of making the KUNIT_* macros take
up less stack space.

[Linus Torvalds]

On Wed, Sep 8, 2021 at 2:25 PM Brendan Higgins
<brendan...@google.com> wrote:
>
> I definitely agree that in the cases where KUnit is not actually
> contributing to blowing the stack - struct leak just thinks it is,
> this is fine; however, it sounds like Linus' concerns with KUnit's
> macros go deeper than this.

I don't mind Kunit tests when they don't cause problems, but one very
natural way to use the Kunit test infrastructure does seem to be to
just put a lot of them into one function.

And then the individually fairly small structures just add up.
Probably mainly in some special configurations (ie together with
CONFIG_KASAN_STACK as pointed out by Arnd, but there might be other
cases that cause that issue too) where the compiler then doesn't merge
stack slots.

I wonder if those 'kunit_assert' structures could be split into two:
one part that could be 'static const', and at least shrink the dynamic
stack use that way. Because at a minimun, things like
type/file/line/format-msg seem to be things that really are just
static and const.

Hmm?

Linus

[Shuah Khan]

Brendan,

Would you like to send me the fix with Suggested-by for Arnd or Kees?

thanks,
-- Shuah

[Brendan Higgins]

So it looks like Arnd's fix was accepted (whether by him or someone
else) for property-entry-test and Linus already fixed thunderbolt, so
the only remaining of Arnd's patches is for the bitfield test, so I'll
resend that one in a bit.

Also, I haven't actually tried Linus' suggestion yet, but the logic is
sound and the change *should* be fairly unintrusive - I am going to
give that a try and report back (but I will get the bitfield
structleak disable patch out first since I already got that applying).

[Arnd Bergmann]

Looking at my randconfig tree, I find these six instances:

$ git grep -w DISABLE_STRUCTLEAK_PLUGIN
drivers/base/test/Makefile:CFLAGS_property-entry-test.o +=
$(DISABLE_STRUCTLEAK_PLUGIN)
drivers/iio/test/Makefile:CFLAGS_iio-test-format.o +=
$(DISABLE_STRUCTLEAK_PLUGIN)
drivers/mmc/host/Makefile:CFLAGS_sdhci-of-aspeed.o +=
$(DISABLE_STRUCTLEAK_PLUGIN)
drivers/thunderbolt/Makefile:CFLAGS_test.o += $(DISABLE_STRUCTLEAK_PLUGIN)
lib/Makefile:CFLAGS_test_scanf.o += $(DISABLE_STRUCTLEAK_PLUGIN)
lib/Makefile:CFLAGS_bitfield_kunit.o += $(DISABLE_STRUCTLEAK_PLUGIN)
scripts/Makefile.gcc-plugins: DISABLE_STRUCTLEAK_PLUGIN +=
-fplugin-arg-structleak_plugin-disable
scripts/Makefile.gcc-plugins:export DISABLE_STRUCTLEAK_PLUGIN

Sorry for failing to submit these as a proper patch. If you send a new version,
I think you need to make sure you cover all of the above, using whichever
change you like best.

Arnd

[Brendan Higgins]

Alright, I incorporated all the above into a patchset that I think is
ready to send out, but I had a couple of issues with the above
suggestions:

- I could not find a config which causes a stacksize warning for
sdhci-of-aspeed.
- test_scanf is not a KUnit test.
- Linus already fixed the thunderbolt test by breaking up the test cases.

I am going to send out patches for the thunderbolt test and for the
sdhci-of-aspeed test for the sake of completeness, but I am not sure
if we should merge those two. I'll let y'all decide on the patch
review.

I only based the thunderbolt and bitfield test fixes on actual patches
from Arnd, but I think Arnd pretty much did all the work here so I am
crediting him with a Co-developed-by on all the other patches, so
Arnd: please follow up on the other patches with a signed-off-by,
unless you would rather me credit you in some other way.

> Sorry for failing to submit these as a proper patch. If you send a new version,
> I think you need to make sure you cover all of the above, using whichever
> change you like best.

I am still going to try to get Linus' suggestion working since it
actually solves the problem, but I would rather get the above
suggested fix out there since it is quick and I know it works.

Cheers

[Brendan Higgins]

On Thu, Sep 16, 2021 at 10:39 PM Brendan Higgins

<brendan...@google.com> wrote:
>
> On Tue, Sep 14, 2021 at 3:04 PM Arnd Bergmann <ar...@arndb.de> wrote:
> >
> > On Tue, Sep 14, 2021 at 10:48 PM Brendan Higgins
> > <brendan...@google.com> wrote:
> > >
> > > On Mon, Sep 13, 2021 at 1:55 PM Shuah Khan <sk...@linuxfoundation.org> wrote:
> > > >
> > > > On 9/8/21 3:24 PM, Brendan Higgins wrote:

[...]

> Alright, I incorporated all the above into a patchset that I think is
> ready to send out, but I had a couple of issues with the above
> suggestions:
>
> - I could not find a config which causes a stacksize warning for
> sdhci-of-aspeed.
> - test_scanf is not a KUnit test.
> - Linus already fixed the thunderbolt test by breaking up the test cases.
>
> I am going to send out patches for the thunderbolt test and for the
> sdhci-of-aspeed test for the sake of completeness, but I am not sure
> if we should merge those two. I'll let y'all decide on the patch
> review.

Just in case I missed any interested parties on this thread, I posted
my patches here:

https://lore.kernel.org/linux-kselftest/20210917061104.2680...@google.com/T/#t

[Arnd Bergmann]

On Fri, Sep 17, 2021 at 8:16 AM Brendan Higgins

<brendan...@google.com> wrote:
>
> On Thu, Sep 16, 2021 at 10:39 PM Brendan Higgins
> <brendan...@google.com> wrote:
> >
> > On Tue, Sep 14, 2021 at 3:04 PM Arnd Bergmann <ar...@arndb.de> wrote:
> > >
> > > On Tue, Sep 14, 2021 at 10:48 PM Brendan Higgins
> > > <brendan...@google.com> wrote:
> > > >
> > > > On Mon, Sep 13, 2021 at 1:55 PM Shuah Khan <sk...@linuxfoundation.org> wrote:
> > > > >
> > > > > On 9/8/21 3:24 PM, Brendan Higgins wrote:
> [...]
> > Alright, I incorporated all the above into a patchset that I think is
> > ready to send out, but I had a couple of issues with the above
> > suggestions:

Thanks a lot for those suggestions.

> > - I could not find a config which causes a stacksize warning for
> > sdhci-of-aspeed.

I keep a history of my randconfig builds. This one only happened
once before I fixed it, it may depend on some other combination of
options. See my original defconfig file at
https://pastebin.com/raw/XJxjVGYa
rand/0xAB2DD5A0-failure:/git/arm-soc/drivers/mmc/host/sdhci-of-aspeed-test.c:47:1:
error: the frame size of 1152 bytes is larger than 1024 bytes
[-Werror=frame-larger-than=]

> > - test_scanf is not a KUnit test.

I have three defconfigs for this one, all on x86-64:

rand86/0x30AD57FB-failure:/git/arm-soc/lib/test_scanf.c: In function
'numbers_list_field_width_val_width':
rand86/0x30AD57FB-failure:/git/arm-soc/lib/test_scanf.c:530:1: error:
the frame size of 2488 bytes is larger than 2048 bytes
[-Werror=frame-larger-than=]
rand86/0x30AD57FB-failure:/git/arm-soc/lib/test_scanf.c: In function
'numbers_list_field_width_typemax':
rand86/0x30AD57FB-failure:/git/arm-soc/lib/test_scanf.c:488:1: error:
the frame size of 2968 bytes is larger than 2048 bytes
[-Werror=frame-larger-than=]
rand86/0x30AD57FB-failure:/git/arm-soc/lib/test_scanf.c: In function
'numbers_list':
rand86/0x30AD57FB-failure:/git/arm-soc/lib/test_scanf.c:437:1: error:
the frame size of 2488 bytes is larger than 2048 bytes
[-Werror=frame-larger-than=]

https://pastebin.com/raw/jUdY6d3G is the worst one of those

> > - Linus already fixed the thunderbolt test by breaking up the test cases.

Ok.

> > I am going to send out patches for the thunderbolt test and for the
> > sdhci-of-aspeed test for the sake of completeness, but I am not sure
> > if we should merge those two. I'll let y'all decide on the patch
> > review.
>
> Just in case I missed any interested parties on this thread, I posted
> my patches here:
>
> https://lore.kernel.org/linux-kselftest/20210917061104.2680...@google.com/T/#t

Thanks! I'll reply to the particular patch as well, but I don't think
that this is
sufficient here:

+CFLAGS_bitfield_kunit.o := $(call
cc-option,-Wframe-larger-than=10240) $(DISABLE_STRUCTLEAK_PLUGIN)

If 10KB is actually needed, this definitely overflows the 8KB stack on
32-bit architectures.

Arnd