On Thu, Aug 8, 2024 at 11:46 AM Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote: > > * Jeff Xu <jeffxu@xxxxxxxxxx> [240808 14:37]: > > On Thu, Aug 8, 2024 at 11:08 AM Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote: > > > > > > * Jeff Xu <jeffxu@xxxxxxxxxx> [240807 23:37]: > > > > 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. > > > > > > Yes, but it should be handled by vm_ops->close() when MAP_FIXED unmaps > > > the vdso. Note that you cannot MAP_FIXED over half of the vma as the > > > vm_ops->may_split() is special_mapping_split(), which just returns > > > -EINVAL. > > > > > The may_split() failure logic is specific to vm_special_mapping, right ? > > Not really, it's just what exists for these vmas vm_ops struct. It's > called on every vma for every split in __split_vma(). > > > > > Do we still need to keep vm_special_mapping struct , if we are going to > > treat special vma as normal vma ? > > No, just set the vm_ops may_split to something that returns -EINVAL. > OK, that makes sense. Thanks
