Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression

[Linus Torvalds <torvalds@linux-foundation.org>]

On Mon, 5 Aug 2024 at 19:01, Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> >
> > I just don't quite know _why_ powerpc cares.
>
> AFAIK for CRIU the problem is signal delivery:

Hmm. Well, the patch I sent out should keep it all working.

In fact, to some degree it would make it much more straightforward for
other architectures to do the same thing.

Instead of a random "arch_munmap()" hack, it's a fairly reasonable
_install_special_mapping() extension.

That said, the *other* thing I don't really understand is the strange
"we have to set the context.vdso value before calling
install_special_mapping":

        /*
         * Put vDSO base into mm struct. We need to do this before calling
         * install_special_mapping or the perf counter mmap tracking code
         * will fail to recognise it as a vDSO.
         */

and that looks odd too.

Anyway, I wish we could just get rid of all the horrible signal restore crap.

We used to just put it in the stack, and that worked really well apart
from the whole WX thing.

I wonder if we should just go back to that, and turn the resulting
"page fault due to non-executable stack" into a "sigreturn system
call".

And yes, SA_RESTORER is the right thing. It's basically just user
space telling us where it is. And happily, on x86-64 we just forced
the issue, and we do

        /* x86-64 should always use SA_RESTORER. */
        if (!(ksig->ka.sa.sa_flags & SA_RESTORER))
                return -EFAULT;

so you literally cannot have signals without it.

             Linus