lkml.org 
[lkml]   [2023]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [GIT PULL] KUnit next update for Linux 6.3-rc1
On Sat, 25 Feb 2023 at 08:25, David Gow <davidgow@google.com> wrote:
>
> On Sat, 25 Feb 2023 at 07:23, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Tue, Feb 21, 2023 at 5:51 PM Shuah Khan <skhan@linuxfoundation.org> wrote:
> > >
> > > This KUnit update for Linux 6.3-rc1 consists of cleanups, new features,
> > > and documentation updates:
> >
> > Hmm. I have not actually bisected this or tried to otherwise figure
> > out exactly what is wrong, but the kunit code ends up being really
> > annoying for my build testing.
>
> This will be due to 7170b7ed6acb ("kunit: Add "hooks" to call into
> KUnit when it's built as a module").
>
> The "hooks.o" file is special in that it needs to be built-in even
> when the other KUnit files are built as a module, and clearly the
> kbuild hackery for that has fallen apart.
>
> >
> > In particular, if I do
> >
> > make
> >
> > repeatedly - ie with no other changes in between - the kunit code ends
> > up re-building itself for no apparent reason.
> >
> > Which then causes a re-link and makes it all really slow.
> >
> > Maybe I'm barking up the wrong tree, but just do
> >
> > make allmodconfig
> >
> > and then do two plain "make"s in succession (feel free to add "-jXYZ"
> > to make it go much faster ;).
> >
> > The second build - that shouldn't have to re-build anything - still does this:
> >
> > CALL scripts/checksyscalls.sh
> > DESCEND objtool
> > CHK kernel/kheaders_data.tar.xz
> > CC lib/kunit/hooks.o
> > AR lib/built-in.a
> > CC lib/kunit/hooks.o
> > AR lib/kunit/lib.a
> > AR built-in.a
> > AR vmlinux.a
> > LD vmlinux.o
> > ...
> >
> > and it all takes much longer than an empty kernel build _should_ take.
>
> As best I can tell, this is kbuild getting very confused by the way
> we're adding lib/kunit/hooks.o directly in lib/Makefile (rather than
> going through lib/kunit/Makefile).
>
> Moving lib/kunit/hooks.c -> lib/kunit_hooks.c and adjusting the
> makefile to match _seems_ to fix it here:
> ---
> diff --git a/lib/Makefile b/lib/Makefile
> index 469be6240523..bb87df427cff 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -131,10 +131,8 @@ obj-$(CONFIG_KUNIT) += kunit/
> # Include the KUnit hooks unconditionally. They'll compile to nothing if
> # CONFIG_KUNIT=n, otherwise will be a small table of static data (static key,
> # function pointers) which need to be built-in even when KUnit is a module.
> -ifeq ($(CONFIG_KUNIT), m)
> -obj-y += kunit/hooks.o
> -else
> -obj-$(CONFIG_KUNIT) += kunit/hooks.o
> +ifdef CONFIG_KUNIT
> +obj-y += kunit_hooks.o
> endif
> ---
>
> Splitting the KUnit code up like that is a little bit ugly, so I'm
> open to any suggestions of how better to structure it.
>
> Regardless, I'll play around a bit and see if I can come up with
> anything better before sending that out.

I managed to get it working by always recursing into the kunit/
directory with obj-y, which is cleaner.
So this patch should fix it:
https://lore.kernel.org/linux-kselftest/20230225014529.2259752-1-davidgow@google.com/T/#u

Sorry again,
-- David
[unhandled content-type:application/pkcs7-signature]
\
 
 \ /
  Last update: 2023-03-27 00:35    [W:0.054 / U:3.932 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site