* Suren Baghdasaryan <surenb@xxxxxxxxxx> [241218 12:58]:
> On Wed, Dec 18, 2024 at 9:44 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> >
> > On Wed, Dec 18, 2024 at 09:36:42AM -0800, Suren Baghdasaryan wrote:
> >
> > > > You will not. vms_complete_munmap_vmas() will call remove_vma() to
> > > > remove PTEs IIRC, and if you do start_write() and detach() before
> > > > dropping mmap_lock_write, you should be good.
> > >
> > > Ok, I think we will have to move mmap_write_downgrade() inside
> > > vms_complete_munmap_vmas() to be called after remove_vma().
> > > vms_clear_ptes() is using vmas, so we can't move remove_vma() before
> > > mmap_write_downgrade().
> >
> > Why ?!
> >
> > vms_clear_ptes() and remove_vma() are fine where they are -- there is no
> > concurrency left at this point.
> >
> > Note that by doing vma_start_write() inside vms_complete_munmap_vmas(),
> > which is *after* the vmas have been unhooked from the mm, you wait for
> > any concurrent user to go away.
> >
> > And since they're unhooked, there can't be any new users.
> >
> > So you're the one and only user left, and code is fine the way it is.
>
> Ok, let me make sure I understand this part of your proposal. From
> your earlier email:
>
> @@ -1173,6 +1173,11 @@ static void vms_complete_munmap_vmas(struct
> vma_munmap_struct *vms,
> struct vm_area_struct *vma;
> struct mm_struct *mm;
>
> + mas_for_each(mas_detach, vma, ULONG_MAX) {
> + vma_start_write(next);
> + vma_mark_detached(next, true);
> + }
> +
> mm = current->mm;
> mm->map_count -= vms->vma_count;
> mm->locked_vm -= vms->locked_vm;
>
> This would mean:
>
> vms_complete_munmap_vmas
> vma_start_write
> vma_mark_detached
> mmap_write_downgrade
> vms_clear_ptes
> remove_vma
>
> And remove_vma will be just freeing the vmas. Is that correct?
> I'm a bit confused because the original thinking was that
> vma_mark_detached() would drop the last refcnt and if it's 0 we would
> free the vma right there. If that's still what we want to do then I
> think the above sequence should look like this:
>
> vms_complete_munmap_vmas
> vms_clear_ptes
> remove_vma
> vma_start_write
> vma_mark_detached
> mmap_write_downgrade
>
> because vma_start_write+vma_mark_detached should be done under mmap_write_lock.
> Please let me know which way you want to move forward.
>
Are we sure we're not causing issues with the MAP_FIXED path here?
With the above change, we'd be freeing the PTEs before marking the vmas
as detached or vma_start_write().
