[PATCH 1/1] mm/nommu: remove unnecessary VMA locking

Suren Baghdasaryan surenb at google.com
Fri Mar 3 12:34:33 AEDT 2023


On Thu, Mar 2, 2023 at 1:41 AM David Hildenbrand <david at redhat.com> wrote:
>
> On 01.03.23 20:04, Suren Baghdasaryan wrote:
> > Since CONFIG_PER_VMA_LOCK depends on CONFIG_MMU, the changes in nommu
> > are not needed. Remove them.
> >
> > Fixes: bad94decd6a4 ("mm: write-lock VMAs before removing them from VMA tree")
> > Reported-by: Hyeonggon Yoo <42.hyeyoo at gmail.com>
> > Link: https://lore.kernel.org/all/Y%2F8CJQGNuMUTdLwP@localhost/
> > Signed-off-by: Suren Baghdasaryan <surenb at google.com>
> > ---
> > Fix cleanly applies over mm-unstable, SHA in "Fixes" is from that tree.
> >
> >   mm/nommu.c | 5 -----
> >   1 file changed, 5 deletions(-)
> >
> > diff --git a/mm/nommu.c b/mm/nommu.c
> > index 2ab162d773e2..57ba243c6a37 100644
> > --- a/mm/nommu.c
> > +++ b/mm/nommu.c
> > @@ -588,7 +588,6 @@ static int delete_vma_from_mm(struct vm_area_struct *vma)
> >                      current->pid);
> >               return -ENOMEM;
> >       }
> > -     vma_start_write(vma);
> >       cleanup_vma_from_mm(vma);
> >
> >       /* remove from the MM's tree and list */
> > @@ -1520,10 +1519,6 @@ void exit_mmap(struct mm_struct *mm)
> >        */
> >       mmap_write_lock(mm);
> >       for_each_vma(vmi, vma) {
> > -             /*
> > -              * No need to lock VMA because this is the only mm user and no
> > -              * page fault handled can race with it.
> > -              */
> >               cleanup_vma_from_mm(vma);
> >               delete_vma(mm, vma);
> >               cond_resched();
>
> So, i assume this should be squashed.

Yes, that would be best.

>
> Reviewed-by: David Hildenbrand <david at redhat.com>

Thanks1

>
>
> Just a general comment: usually, if review of the original series is
> still going on, it makes a lot more sense to raise such things in the
> original series so the author can fixup while things are still in
> mm-unstable. Once the series is in mm-stable, it's a different story. In
> that case, it is usually good to have the mail subjects be something
> like  "[PATCH mm-stable 1/1] ...".

Ok... For my education, do you mean the title of this patch should
somehow reflect that it should be folded into the original patch? Just
trying to understand the actionable item here. How would you change
this patch when posting for mm-unstable and for mm-stable?
Thanks,
Suren.

>
> --
> Thanks,
>
> David / dhildenb
>


More information about the Linuxppc-dev mailing list