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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 25 Feb 2023 08:25:11 +0800
From:   David Gow <davidgow@...gle.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Shuah Khan <skhan@...uxfoundation.org>, shuah <shuah@...nel.org>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] KUnit next update for Linux 6.3-rc1

On Sat, 25 Feb 2023 at 07:23, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Tue, Feb 21, 2023 at 5:51 PM Shuah Khan <skhan@...uxfoundation.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.

Sorry for the inconvenience!

-- David

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4003 bytes)