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

[Benjamin Berg]

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

Benjamin

> 
> <snip>
> 
> 
> Thomas
>