Wait, I figured a better place to do this. init_multi_vma_prep() should vma_start_write() on any VMA that is passed in.. that we we catch any modifications here & in vma_merge(), which I think is missed in this patch set? * Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> [230223 15:20]: > Reviewed-by: Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> > > * Suren Baghdasaryan <surenb@xxxxxxxxxx> [230216 00:18]: > > vma_expand and vma_shrink change VMA boundaries. Expansion might also > > result in freeing of an adjacent VMA. Write-lock affected VMAs to prevent > > concurrent page faults. > > > > Signed-off-by: Suren Baghdasaryan <surenb@xxxxxxxxxx> > > --- > > mm/mmap.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > index ec2f8d0af280..f079e5bbcd57 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -674,6 +674,9 @@ int vma_expand(struct vma_iterator *vmi, struct vm_area_struct *vma, > > ret = dup_anon_vma(vma, next); > > if (ret) > > return ret; > > + > > + /* Lock the VMA before removing it */ > > + vma_start_write(next); > > } > > > > init_multi_vma_prep(&vp, vma, NULL, remove_next ? next : NULL, NULL); > > @@ -686,6 +689,7 @@ int vma_expand(struct vma_iterator *vmi, struct vm_area_struct *vma, > > if (vma_iter_prealloc(vmi)) > > goto nomem; > > > > + vma_start_write(vma); > > vma_adjust_trans_huge(vma, start, end, 0); > > /* VMA iterator points to previous, so set to start if necessary */ > > if (vma_iter_addr(vmi) != start) > > @@ -725,6 +729,7 @@ int vma_shrink(struct vma_iterator *vmi, struct vm_area_struct *vma, > > if (vma_iter_prealloc(vmi)) > > return -ENOMEM; > > > > + vma_start_write(vma); > > init_vma_prep(&vp, vma); > > vma_adjust_trans_huge(vma, start, end, 0); > > vma_prepare(&vp); > > -- > > 2.39.1 > >
