linux-kernel - Re: [PATCH 5/8] mmap locking API: convert nested write lock sites

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]

Date:   Thu, 26 Mar 2020 05:56:43 -0700
From:   Michel Lespinasse <walken@...gle.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        linux-mm <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Laurent Dufour <ldufour@...ux.ibm.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Liam Howlett <Liam.Howlett@...cle.com>,
        Jerome Glisse <jglisse@...hat.com>,
        Davidlohr Bueso <dave@...olabs.net>,
        David Rientjes <rientjes@...gle.com>,
        Hugh Dickins <hughd@...gle.com>, Ying Han <yinghan@...gle.com>
Subject: Re: [PATCH 5/8] mmap locking API: convert nested write lock sites

On Thu, Mar 26, 2020 at 5:09 AM Matthew Wilcox <willy@...radead.org> wrote:
> On Thu, Mar 26, 2020 at 12:02:33AM -0700, Michel Lespinasse wrote:
> > @@ -47,9 +48,9 @@ static inline void activate_mm(struct mm_struct *old, struct mm_struct *new)
> >        * when the new ->mm is used for the first time.
> >        */
> >       __switch_mm(&new->context.id);
> > -     down_write_nested(&new->mmap_sem, 1);
> > +     mmap_write_lock_nested(new, 1);
> >       uml_setup_stubs(new);
> > -     mmap_write_unlock(new);
> > +     mmap_write_unlock_nested(new);
>
> This is a bit of an oddity.  We don't usually have an unlock_nested()
> variant (a quick grep finds only something complicated in reiserfs).
> That's because it's legitimate to release locks in a different order from
> the one they were acquired in (eg lock A, lock B, unlock A, unlock B), and
> it's not clear whether "nested" would follow the lock (ie unlock_nested B)
> or whether it would follow the code (ie unlock_nested A).
>
> Does your future API require knowing the nested nature at the unlock
> point?  And if so, does it require it for A or B in the above scenario?
> And how does it mix with lock A or B being of a different type (eg a
> plain mutex or a spinlock)?

I'll admit it's a bit unusual.

In MM we have only two uses nested mmap locks (as you can see in this
patch), and they both release locks in the opposite order as they
acquire them. We could probably follow this pattern if additional use
cases end up being needed.

In my range locking patchset, nested locks need to pass an explicit
lock range. Also when implementing mmap_sem locking latencies, it can
be convenient to ignore the nested locks under the assumption that
their hold interval is contained within the outer lock's hold
interval.

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.