[PATCH v6 00/13] nommu UML

[Benjamin Berg]

Hi,

On Wed, 2025-01-15 at 09:25 +0900, Hajime Tazaki wrote:
> On Wed, 15 Jan 2025 03:53:36 +0900,
> Benjamin Berg wrote:
> > 
> > On Tue, 2025-01-14 at 20:30 +0900, Hajime Tazaki wrote:
> > > This patchset is another spin of nommu mode addition to UML.  It doesn't
> > > change a lot since the last version (v5), but contain clean ups.  It would
> > > be nice to hear about your opinions on that.
> > > 
> > > There are still several limitations/issues which we already found;
> > > here is the list of those issues.
> > > 
> > > - memory mapped by loadable modules are not distinguished from
> > >   userspace memory.
> > 
> > Maybe I am missing it, but I do not yet see proper FP register
> > handling. This will be needed for task/thread switches and also signal
> > emission/sigreturn. I am attaching the test program that I used to
> > verify the correct behaviour when dealing with the recent changes to FP
> > register handling in UML.
> 
> thanks for the test program.
> 
> I didn't address your comment on FP register handling as I couldn't
> see any reproducer that causes the issue you raised (and maybe didn't
> understand well the problem) so, the attached program helps a lot.

Note that it doesn't directly test task/thread switches which only
happen due to normal scheduling (i.e. via SIGALRM). So, it doesn't
cover everything, but syscalls and signals are quite important by
themselves. For normal UML both cases hit the same codepath, but I
think in your case the SIGALRM entry point differs and should be tested
separately.

> Though nommu code only works with musl-libc, which I cannot use that
> as-is, now I see what you meant with the first function, test_fp().
> 
> (none):/# /root/test-signal-restore
> pre-signal: 0.5
> post-signal: 0.5
> floating point register was not manipulated
> 
> Tests on task switch (test_fp_ptrace) might need more work for me as
> nommu only works with vfork(2) and vfork without exec(2) may not test
> well on the implementation.

Not sure you even have a working ptrace in nommu?

That reminds me. Please set arch_has_single_step to zero for nommu
mode. If you figure out how to set the appropriate bit in EFLAGS when
returning to userspace, then that would also work.

> and also I'm wishing to have this kind of useful tests as a reusable
> way; as now I'm going to add a new configuration for UML, you're also
> going for another SECCOMP mode over MMU, we may have at least 3
> running modes for UML, which I think we should share the test
> framework that we should pass.  Not sure how it should be but using
> Kunit is the first thing in my mind.

My problem was, that I didn't know of a good place to put it. We could
probably drop this test into tools/testing/selftests/x86, but how is it
run then?
As for kunit, that would be neat, but I it seems a bit more complicated
to run userspace code from within the kernel.

Benjamin

> I'd like to work on such things once I've done this initial part for
> nommu.
> 
> thanks, will get back here once I could see the right way to fix it.
> 
> -- Hajime
> 
>