On Wed, Aug 7, 2024 at 8:21 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > 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. > This is a new point that I didn't realize before, if we are going to handle unmap vdso safely, yes, this is a bugfix that should be applied everywhere for all arch, without CHECKPOINT_RESTORE config. Do we need to worry about mmap(fixed) ? which can have the same effect as mremap. > 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
