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.
>
>
