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!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
On Tue, Feb 21, 2023 at 5:51 PM Shuah Khan <[email protected]> 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
<[email protected]> wrote:
>
> On Tue, Feb 21, 2023 at 5:51 PM Shuah Khan <[email protected]> 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
On Sat, 25 Feb 2023 at 08:25, David Gow <[email protected]> wrote:
>
> On Sat, 25 Feb 2023 at 07:23, Linus Torvalds
> <[email protected]> wrote:
> >
> > On Tue, Feb 21, 2023 at 5:51 PM Shuah Khan <[email protected]> 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/[email protected]/T/#u
Sorry again,
-- David