[RFC 0/2] Experimental kunit test for signal context handling

[Thomas Weißschuh]

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-01aab312f56b@linutronix.de/

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?

<snip>


Thomas