On Fri, Jun 27, 2025 at 10:48:30AM +0200, Benjamin Berg wrote:
> Hi,
>
> On Fri, 2025-06-27 at 10:43 +0200, Thomas Weißschuh wrote:
> > On Fri, Jun 27, 2025 at 09:29:12AM +0200, Benjamin Berg wrote:
> > > On Fri, 2025-06-27 at 06:33 +0200, Thomas Weißschuh wrote:
> > > > On Thu, Jun 26, 2025 at 09:57:12PM +0200, Benjamin Berg wrote:
> > > > > so I saw the UAPI testing framework patches and wondered whether I
> > > > > could
> > > > > hack up a kunit test for userspace signal mcontext handling. I already
> > > > > had some code, but never knew where to include it. Having it as a
> > > > > kunit
> > > > > test in this way seems nice as it makes running the test really
> > > > > simple.
> > > >
> > > > Nice to hear that you find it useful.
> > > >
> > > > > This is a very rough attempt with an extra patch to add sigaction
> > > > > support as that is needed by the test.
> > > > >
> > > > > Note that this type of test could possibly be shared with the x86
> > > > > architecture (though UM does not support all features).
> > > >
> > > > Can the expected feature detection be performed at runtime?
> > > > If so I would write the test as x86 kselftest in
> > > > tools/testing/kselftests/x86/
> > > > and then also hook it up for kunit on UML and x86.
> > > > This gives you the advantages of all worlds.
> > > >
> > > > For an example see [0]. That is still based on an old version of the
> > > > framework,
> > > > so can't be used as-is. But you should get the idea.
> > >
> > > That looks nice, and you do support both x86 and um there!
> > >
> > > Many of those checks should be simple as syscalls will return an error
> > > (modify_ldt should return -ENOSYS for example). For more arcane things
> > > one could e.g. add "(um)" into AT_PLATFORM or just disable the kunit
> > > test for the um architecture.
> >
> > Sounds good.
> >
> > > This is a nice development, I absolutely expect to find some bugs in um
> > > this way.
> >
> > I do so, too :-)
> >
> > https://lore.kernel.org/lkml/20250617-uml-tick-timer-v1-1-01aab312f...@linutronix.de/
>
> Ah, yes, that one :-)
>
> > To be honest if there are going to be a bunch of issues on UML,
> > I'd prefer to drop the UML bits from my submissions.
> > I'm not familiar with UML and can't really fix the fallout.
> > Then you can wire up the tests with a few lines and handle the fallout at
> > your convenience.
> >
> > Or we gate the testcases behind BROKEN/EXPORT on UML in the beginning.
> >
> > Does this sound reasonable?
>
> Not sure how to gate them, but I do like the idea of being able to
> enable them using only minor modifications or even a Kconfig option to
> see what happens on UM.
With my WIP x86 enablement commit as example [0].
Possibility 1, I *drop* these two hunks, you can readd them:
diff --git a/arch/x86/um/Kconfig b/arch/x86/um/Kconfig
index 986045d5e63854..f2aeaf1e8e6d9a 100644
--- a/arch/x86/um/Kconfig
+++ b/arch/x86/um/Kconfig
@@ -3,6 +3,7 @@
menu "Host processor type and features"
source "arch/x86/Kconfig.cpu"
+source "arch/x86/tests/Kconfig"
endmenu
diff --git a/arch/x86/um/Makefile b/arch/x86/um/Makefile
index b42c31cd2390cb..e71bb244afac9d 100644
--- a/arch/x86/um/Makefile
+++ b/arch/x86/um/Makefile
@@ -13,7 +13,7 @@ obj-y = bugs_$(BITS).o delay.o fault.o \
ptrace.o ptrace_$(BITS).o ptrace_user.o setjmp_$(BITS).o signal.o \
stub_segv.o \
sys_call_table_$(BITS).o sysrq_$(BITS).o tls_$(BITS).o \
- mem_$(BITS).o subarch.o os-Linux/
+ mem_$(BITS).o subarch.o os-Linux/ ../tests/
ifeq ($(CONFIG_X86_32),y)
Possibility 2, the kconfig looks like this:
config X86_UAPI_TEST
tristate "x86 UAPI tests" if !KUNIT_ALL_TESTS
depends on KUNIT_UAPI
depends on !UML || BROKEN
default KUNIT_ALL_TESTS
You enable CONFIG_BROKEN and can run the tests.
Of course as soon as all tests work on UML, this all goes away and they
stay enabled.
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/thomas.weissschuh/linux.git/commit/?h=kunit-kselftests-integration&id=14bf93f09eaa328a18e9190f46fa4ee697378617
