linux-kernel - Re: [PATCH v5 00/15] kunit: Introduce UAPI testing framework

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]

Message-ID: <20250718073743-d4a1f713-f81b-4e89-b3f8-7eed838798e6@linutronix.de>
Date: Fri, 18 Jul 2025 08:22:26 +0200
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Christoph Hellwig <hch@....de>
Cc: Masahiro Yamada <masahiroy@...nel.org>, 
	Nathan Chancellor <nathan@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, 
	Willy Tarreau <w@....eu>, Thomas Weißschuh <linux@...ssschuh.net>, 
	Brendan Higgins <brendan.higgins@...ux.dev>, David Gow <davidgow@...gle.com>, Rae Moar <rmoar@...gle.com>, 
	Shuah Khan <shuah@...nel.org>, Jonathan Corbet <corbet@....net>, 
	Nicolas Schier <nicolas.schier@...ux.dev>, Kees Cook <kees@...nel.org>, 
	Alexander Viro <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>, 
	Luis Chamberlain <mcgrof@...nel.org>, Christophe Leroy <christophe.leroy@...roup.eu>, 
	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org, 
	kunit-dev@...glegroups.com, linux-doc@...r.kernel.org, workflows@...r.kernel.org, 
	linux-mm@...ck.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v5 00/15] kunit: Introduce UAPI testing framework

On Thu, Jul 17, 2025 at 03:23:00PM +0200, Christoph Hellwig wrote:
> On Thu, Jul 17, 2025 at 10:48:02AM +0200, Thomas Weißschuh wrote:

(...)

> > This series aims to combine kselftests and kunit, avoiding both their
> > limitations. It works by compiling the userspace kselftests as part of
> > the regular kernel build, embedding them into the kunit kernel or module
> > and executing them from there.

(...)

> I had my own fair share of problems with kselftests,
> mostly because of the lack of structure and automated way to run them,

How did you overcome these issues? Why does everbody need to reinvent the
wheel here? KUnit already exists and provides a lot of structure and tooling.

> but adding them to the kernel (or a module) is overshooting the target
> by far.

That's a subjective statement without any reasoning I can engange with.
I would be happy to do so, but for now I can only say that I disagree.
The patches have been on the testing-related lists for
some time and so far nobody had an issue with this aspect.

> > If the kernel toolchain is not fit to
> > produce userspace because of a missing libc, the kernel's own nolibc can
> > be used instead.
> 
> Is nolibc enough to run all the selftests?

It is not and most probably won't ever be. The maintainers of each testcase
will decide which libc to use. Like it is in tools/testing/selftests/ today.
Some use glibc, some nolibc and some can do both.

> If so we should just do it unconditionally, but linking to different
> libraries by availability seems a bit problematic.

Agreed. But as mentioned above it will be the maintainers decision.

Only the preinit executable will need to support all configurations so needs
the availability check. For the framework selftest it also makes sense to
support as many configurations as possible. For the example test, any
configuration is fine. 

(...)

While having this discussion, can we also work on dealing with the symbol
exports, as discussed before?

Thomas