On Wed, 7 Aug 2024 at 16:20, Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote:
>
> Okay, I'm going to try one more time here. You are suggesting to have a
> conf flag to leave the vdso pointer unchanged when it is unmapped.
> Having the close behind the conf option will not prevent it from being
> unmapped or mapped over, so what you are suggesting is have a
> configuration option that leaves a pointer, mm->context.vdso, to be
> unsafe if it is unmapped if you disable checkpoint restore.
We definitely do not want that kind of complexity. It makes the kernel
just more complicated to have to deal with both cases.
That said, I don't love how special powerpc is here.
What we could do is to is
- stop calling these things "special mappings", and just admit that
it's for different vdso mappings and nothing else (for some odd reason
arm and nios2 calls it a "kuser helper" rather than vdso, but it's the
exact same thing)
- don't do this whole indirect function pointer thing with mremap and
close at all, and just do this all unapologetically and for all
architectures in the generic VM layer together with "if (vma->vm_start
== mm->context.vdso)" etc.
that would get rid of the conceptual complexity of having different
architectures doing different things (and the unnecessary overhead of
having an indirect function pointer that just points to one single
thing).
But I think the current "clean up the existing mess" is probably the
less invasive one over "make the existing mess be explicitly about
vdso and avoid unnecessary per-architecture differences".
If people want to, we can do the unification (and stop pretending the
"special mappings" could be something else) later.
Linus
