Re: [PATCH 1/2] mm: protect free_pgtables with mmap_lock write lock in exit_mmap

From: Suren Baghdasaryan <surenb@google.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	akpm@linux-foundation.org, rientjes@google.com,
	hannes@cmpxchg.org, guro@fb.com, riel@surriel.com,
	minchan@kernel.org, kirill@shutemov.name, aarcange@redhat.com,
	christian@brauner.io, hch@infradead.org, oleg@redhat.com,
	david@redhat.com, jannh@google.com, shakeelb@google.com,
	luto@kernel.org, christian.brauner@ubuntu.com,
	fweimer@redhat.com, jengelh@inai.de, timmurray@google.com,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	kernel-team@android.com
Subject: Re: [PATCH 1/2] mm: protect free_pgtables with mmap_lock write lock in exit_mmap
Date: Wed, 24 Nov 2021 16:01:06 -0800	[thread overview]
Message-ID: <CAJuCfpFCoP02tXYxjQG9u3pLqbzMiKebXN25QpMMjP2CZ-r7Pw@mail.gmail.com> (raw)
In-Reply-To: <CAJuCfpHOTiKNgsGQJR=_6bx=p_WuhwCEQhFe8K60JCA7muYRYQ@mail.gmail.com>

On Wed, Nov 24, 2021 at 7:25 AM Suren Baghdasaryan <surenb@google.com> wrote:
>
> On Wed, Nov 24, 2021 at 4:20 AM Michal Hocko <mhocko@suse.com> wrote:
> >
> > On Tue 23-11-21 09:56:41, Suren Baghdasaryan wrote:
> > > On Tue, Nov 23, 2021 at 5:19 AM Matthew Wilcox <willy@infradead.org> wrote:
> > > >
> > > > On Tue, Nov 16, 2021 at 01:57:14PM -0800, Suren Baghdasaryan wrote:
> > > > > @@ -3170,6 +3172,7 @@ void exit_mmap(struct mm_struct *mm)
> > > > >       unmap_vmas(&tlb, vma, 0, -1);
> > > > >       free_pgtables(&tlb, vma, FIRST_USER_ADDRESS, USER_PGTABLES_CEILING);
> > > > >       tlb_finish_mmu(&tlb);
> > > > > +     mmap_write_unlock(mm);
> > > > >
> > > > >       /*
> > > > >        * Walk the list again, actually closing and freeing it,
> > > >
> > > > Is there a reason to unlock here instead of after the remove_vma loop?
> > > > We'll need the mmap sem held during that loop when VMAs are stored in
> > > > the maple tree.
> > >
> > > I didn't realize remove_vma() would need to be protected as well. I
> > > think I can move mmap_write_unlock down to cover the last walk too
> > > with no impact.
> > > Does anyone know if there was any specific reason to perform that last
> > > walk with no locks held (as the comment states)? I can track that
> > > comment back to Linux-2.6.12-rc2 merge with no earlier history, so not
> > > sure if it's critical not to hold any locks at this point. Seems to me
> > > it's ok to hold mmap_write_unlock but maybe I'm missing something?
> >
> > I suspect the primary reason was that neither fput (and callbacks
> > invoked from it) nor vm_close would need to be very careful about
> > interacting with mm locks. fput is async these days so it shouldn't be
> > problematic. vm_ops->close doesn't have any real contract definition AFAIK
> > but taking mmap_sem from those would be really suprising. They should be
> > mostly destructing internal vma state and that shouldn't really require
> > address space protection.
>
> Thanks for clarification, Michal. I'll post an updated patch with
> remove_vma() loop executed under mmap_write_lock protection.

v2 is posted at
https://lore.kernel.org/all/20211124235906.14437-1-surenb@google.com/

>
> > --
> > Michal Hocko
> > SUSE Labs