Hi Linus,
Please pull the following KUnit next update for Linux 6.3-rc1.
This KUnit update for Linux 6.3-rc1 consists of cleanups, new features, and documentation updates:
-- adds Function Redirection API to isolate the code being tested from other parts of the kernel. functionredirection.rst has the details.
diff is attached.
thanks, -- Shuah
---------------------------------------------------------------- The following changes since commit 4ec5183ec48656cec489c49f989c508b68b518e3:
Linux 6.2-rc7 (2023-02-05 13:13:28 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest tags/linux-kselftest-kunit-6.3-rc1
for you to fetch changes up to 82649c7c0da431d147a75c6ae768ee42c1053f53:
kunit: Add printf attribute to fail_current_test_impl (2023-02-08 18:08:14 -0700)
---------------------------------------------------------------- linux-kselftest-kunit-6.3-rc1
This KUnit update for Linux 6.3-rc1 consists of cleanups, new features, and documentation updates:
-- adds Function Redirection API to isolate the code being tested from other parts of the kernel. functionredirection.rst has the details.
---------------------------------------------------------------- Alexander Pantyukhin (2): tools/testing/kunit/kunit.py: remove redundant double check kunit: kunit.py extract handlers
David Gow (3): kunit: Add "hooks" to call into KUnit when it's built as a module kunit: Expose 'static stub' API to redirect functions kunit: Add printf attribute to fail_current_test_impl
Rae Moar (1): lib/hashtable_test.c: add test for the hashtable structure
Sadiya Kazi (1): Documentation: Add Function Redirection API docs
.../dev-tools/kunit/api/functionredirection.rst | 162 +++++++++++ Documentation/dev-tools/kunit/api/index.rst | 13 +- Documentation/dev-tools/kunit/usage.rst | 15 +- include/kunit/static_stub.h | 113 ++++++++ include/kunit/test-bug.h | 29 +- lib/Kconfig.debug | 13 + lib/Makefile | 9 + lib/hashtable_test.c | 317 +++++++++++++++++++++ lib/kunit/Makefile | 4 + lib/kunit/hooks-impl.h | 31 ++ lib/kunit/hooks.c | 21 ++ lib/kunit/kunit-example-test.c | 38 +++ lib/kunit/static_stub.c | 123 ++++++++ lib/kunit/test.c | 15 +- tools/testing/kunit/kunit.py | 186 ++++++------ 15 files changed, 966 insertions(+), 123 deletions(-) create mode 100644 Documentation/dev-tools/kunit/api/functionredirection.rst create mode 100644 include/kunit/static_stub.h create mode 100644 lib/hashtable_test.c create mode 100644 lib/kunit/hooks-impl.h create mode 100644 lib/kunit/hooks.c create mode 100644 lib/kunit/static_stub.c ----------------------------------------------------------------
The pull request you sent on Tue, 21 Feb 2023 18:50:56 -0700:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest tags/linux-kselftest-kunit-6.3-rc1
has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/89f1a2440a200918676f9e1eeb765b337f735d86
Thank you!
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.
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.
Linus
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
makerepeatedly - 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
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
makerepeatedly - 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@go...
Sorry again, -- David
linux-kselftest-mirror@lists.linaro.org
-
David Gow -
Linus Torvalds -
pr-tracker-bot＠kernel.org -
Shuah Khan