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

From: David Gow
Date: Fri Feb 24 2023 - 19:25:31 EST


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.

Sorry for the inconvenience!

-- David

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