Re: [GIT PULL] KUnit next update for Linux 6.3-rc1

[David Gow]

On Sat, 25 Feb 2023 at 08:25, David Gow <davidgow@xxxxxxxxxx> wrote:
>
> On Sat, 25 Feb 2023 at 07:23, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Tue, Feb 21, 2023 at 5:51 PM Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx/T/#u

Sorry again,
-- David

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature