linux-kernel - Re: [PATCH v3 1/2] mm: protect free_pgtables with mmap_lock write lock in exit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YbEF3mvk3SUr6WHp@casper.infradead.org>
Date:   Wed, 8 Dec 2021 19:22:06 +0000
From:   Matthew Wilcox <willy@...radead.org>
To:     Suren Baghdasaryan <surenb@...gle.com>
Cc:     Michal Hocko <mhocko@...e.com>, akpm@...ux-foundation.org,
        rientjes@...gle.com, hannes@...xchg.org, guro@...com,
        riel@...riel.com, minchan@...nel.org, kirill@...temov.name,
        aarcange@...hat.com, christian@...uner.io, hch@...radead.org,
        oleg@...hat.com, david@...hat.com, jannh@...gle.com,
        shakeelb@...gle.com, luto@...nel.org, christian.brauner@...ntu.com,
        fweimer@...hat.com, jengelh@...i.de, timmurray@...gle.com,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        kernel-team@...roid.com
Subject: Re: [PATCH v3 1/2] mm: protect free_pgtables with mmap_lock write
 lock in exit_mmap

On Wed, Dec 08, 2021 at 11:13:42AM -0800, Suren Baghdasaryan wrote:
> On Wed, Dec 8, 2021 at 8:50 AM Suren Baghdasaryan <surenb@...gle.com> wrote:
> >
> > On Wed, Dec 8, 2021 at 8:05 AM Matthew Wilcox <willy@...radead.org> wrote:
> > >
> > > On Wed, Dec 08, 2021 at 04:51:58PM +0100, Michal Hocko wrote:
> > > > On Wed 08-12-21 15:01:24, Matthew Wilcox wrote:
> > > > > On Tue, Dec 07, 2021 at 03:08:19PM -0800, Suren Baghdasaryan wrote:
> > > > > > > >         /**
> > > > > > > >          * @close: Called when the VMA is being removed from the MM.
> > > > > > > >          * Context: Caller holds mmap_lock.
> > > > > >
> > > > > > BTW, is the caller always required to hold mmap_lock for write or it
> > > > > > *might* hold it?
> > > > >
> > > > > __do_munmap() might hold it for read, thanks to:
> > > > >
> > > > >         if (downgrade)
> > > > >                 mmap_write_downgrade(mm);
> > > > >
> > > > > Should probably say:
> > > > >
> > > > >     * Context: User context.  May sleep.  Caller holds mmap_lock.
> > > > >
> > > > > I don't think we should burden the implementor of the vm_ops with the
> > > > > knowledge that the VM chooses to not hold the mmap_lock under certain
> > > > > circumstances when it doesn't matter whether it's holding the mmap_lock
> > > > > or not.
> > > >
> > > > If we document it like that some code might depend on that lock to be
> > > > held. I think we only want to document that the holder itself is not
> > > > allowed to take mmap sem or a depending lock.
> > >
> > > The only place where we're not currently holding the mmap_lock is at
> > > task exit, where the mmap_lock is effectively held because nobody else
> > > can modify the task's mm.  Besides, Suren is changing that in this patch
> > > series anyway, so it will be always true.
> >
> > Ok, I'll make it a separate patch after the patch that changes
> > exit_mmap and this statement will become always true. Sounds
> > reasonable?
> 
> Actually, while today vma_ops->close is called with mmap_lock held, I
> believe we want this comment to reflect the restrictions on the
> callback itself, not on the user. IOW, we want to say that the
> callback should not take mmap_lock while the caller might or might not
> hold it. If so, I think *might* would make more sense here, like this:
> 
> * Context: User context.  May sleep.  Caller might hold mmap_lock.
> 
> WDYT?

We're documenting the contract between the caller and the callee.
That implies responsibilities on both sides.  For example, we're
placing requirements on the caller that they're not going to tear
down the VMA in interrupt context.  So I preferred what previous-Suren
said to current-Suren, "this statement will become always true".