[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAFd5g45rOLWoC6KQ+YXJpKMirNSfUFj3SrXefBVpmQ2-oi+Siw@mail.gmail.com>
Date: Thu, 16 Jan 2020 07:16:36 -0800
From: Brendan Higgins <brendanhiggins@...gle.com>
To: Kees Cook <keescook@...omium.org>
Cc: Arnd Bergmann <arnd@...db.de>, PMWG CI <pmwg-ci@...aro.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Private Kernel Alias <private-kwg@...aro.org>,
Ard Biesheuvel <ardb@...nel.org>
Subject: Re: kunit stack usage, was: pmwg-ci report v5.5-rc4-147-gc62d43442481
On Wed, Jan 15, 2020 at 5:29 PM Kees Cook <keescook@...omium.org> 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@...aro.org> 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@...il.com>
> > > 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.
Powered by blists - more mailing lists