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

[Benjamin Berg]

Hi,

On Fri, 2025-06-27 at 06:33 +0200, Thomas Weißschuh wrote:
> Hi,
> 
> 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.

This is a nice development, I absolutely expect to find some bugs in um
this way.

> > And, a 64 bit build might even want to include a second 32 bit binary.
> 
> Indeed, for compat binaries we'll probably want some sort of common pattern.
> Unfortunately it's not as easy as building a second binary when CONFIG_COMPAT=y,
> as some architectures have more than 2 supported ABIs. MIPS for example or x86_64
> when counting x32.
> Or maybe we can just pretend that those don't matter.
> Something we can work on when the first series has been merged.

Yes, lets ignore that for now :-)

> > So, I suppose
> > one would ideally want the test to be in arch/x86/tests, with some way
> > to pick up it up in arch/x86/um/tests.
> > 
> > Does this seem sensible in general?
> 
> It does.

Nice!

Benjamin

> 
> > Benjamin
> 
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/thomas.weissschuh/linux.git/commit/?h=kunit-kselftests-integration&id=14bf93f09eaa328a18e9190f46fa4ee697378617
> 
> > 
> > Benjamin Berg (2):
> >   tools/nolibc: add sigaction()
> >   um: add a mcontext FP register handling test
> > 
> >  arch/x86/um/Makefile                     |   2 +
> >  arch/x86/um/tests/Makefile               |  12 +++
> >  arch/x86/um/tests/registers.c            |  22 +++++
> >  arch/x86/um/tests/test-fp-save-restore.c | 118 +++++++++++++++++++++++
> >  tools/include/nolibc/nolibc.h            |   3 +
> >  tools/include/nolibc/signal.h            |  34 +++++++
> >  6 files changed, 191 insertions(+)
> >  create mode 100644 arch/x86/um/tests/Makefile
> >  create mode 100644 arch/x86/um/tests/registers.c
> >  create mode 100644 arch/x86/um/tests/test-fp-save-restore.c
> > 
> > -- 
> > 2.50.0
> > 
>