Re: kunit stack usage, was: pmwg-ci report v5.5-rc4-147-gc62d43442481

[Brendan Higgins]

On Wed, Jan 15, 2020 at 5:29 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>
> On Tue, Jan 07, 2020 at 01:37:07PM +0100, Arnd Bergmann wrote:
> > On Mon, Dec 30, 2019 at 6:16 PM PMWG CI <pmwg-ci@xxxxxxxxxx> wrote:
> > >
> > >
> > > The error/warning: 1 drivers/base/test/property-entry-test.c:214:1: warning: the frame size of 3128 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> > > ... was introduced by commit:
> > >
> > > commit c032ace71c29d513bf9df64ace1885fe5ff24981
> > > Author: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
> > > Date:   Wed Dec 4 10:53:15 2019 -0800
> > >
> > >     software node: add basic tests for property entries
> >
> > This problem is a result of the KUNIT_ASSERTION() definition that puts
> > a local struct on the stack interacting badly with the structleak_plugin
> > when CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL is set in
> > allmodconfig:
>
> Geh, BYREF_ALL strikes again. I'm at LCA currently, but I'd like to try
> to revisit actually fixing the basic-block splitting in the plugin. This
> was looked at before, but I need to dig up the thread.

Sounds ideal.

I almost got the idea I suggested with the union/single copy
implemented, but it turns out that it is much more complicated than I
originally thought. It turns out that I need more than one copy per
struct kunit instance, I need one per active thread associated with a
struct kunit instance. It still seems possible to do this with percpu,
but it also makes the macro factory more complicated as well.

I am now questioning whether the approach I suggested is really any
better than Arnd's approach.

So yeah, I would definitely prefer fixing the struct leak code.

> If a fast fix is needed, I'm fine with disabling BYREF_ALL with KUNIT.
> It's not optimal, but I feel it's on the BYREF_ALL code to solve this. :)

Sounds good to me.