Messages in this thread | | | Date | Thu, 2 Mar 2023 10:41:09 +0100 | Subject | Re: [PATCH 1/1] mm/nommu: remove unnecessary VMA locking | From | David Hildenbrand <> |
| |
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@gmail.com> > Link: https://lore.kernel.org/all/Y%2F8CJQGNuMUTdLwP@localhost/ > Signed-off-by: Suren Baghdasaryan <surenb@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.
Reviewed-by: David Hildenbrand <david@redhat.com>
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] ...".
-- Thanks,
David / dhildenb
| |