Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 3 Nov 2020 09:21:27 -0400
From:   Jason Gunthorpe <jgg@ziepe.ca>
To:     Jann Horn <jannh@google.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Linux-MM <linux-mm@kvack.org>,
        Eric Biederman <ebiederm@xmission.com>,
        Oleg Nesterov <oleg@redhat.com>,
        kernel list <linux-kernel@vger.kernel.org>,
        Will Deacon <will@kernel.org>,
        Kees Cook <keescook@chromium.org>,
        Ingo Molnar <mingo@kernel.org>
Subject: Re: [RFC PATCH resend 3/6] mm: Add refcount for preserving mm_struct
 without pgd
Message-ID: <20201103132127.GK36674@ziepe.ca>
References: <20201016230915.1972840-1-jannh@google.com>
 <20201016230915.1972840-4-jannh@google.com>
 <20201016232153.GD37159@ziepe.ca>
 <CAG48ez1+VzW=Gz+2CKze_kmFYfb9J3PdrkJtxS21EyqGHZMGjw@mail.gmail.com>
 <CAG48ez0ChA80cjg4-=1k8PfXV_4u_YVQay9g_RdrLjbAzch4Gw@mail.gmail.com>
 <CAG48ez1ue84pXoQvdjqiXZSj5_3+2Wq7A9v9D_7=rzEFac2AFg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAG48ez1ue84pXoQvdjqiXZSj5_3+2Wq7A9v9D_7=rzEFac2AFg@mail.gmail.com>
Precedence: bulk

On Tue, Nov 03, 2020 at 04:19:11AM +0100, Jann Horn wrote:
> On Tue, Nov 3, 2020 at 3:11 AM Jann Horn <jannh@google.com> wrote:
> > On Sat, Oct 17, 2020 at 2:30 AM Jann Horn <jannh@google.com> wrote:
> > > On Sat, Oct 17, 2020 at 1:21 AM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > > > On Sat, Oct 17, 2020 at 01:09:12AM +0200, Jann Horn wrote:
> > > > > Currently, mm_struct has two refcounts:
> > > > >
> > > > >  - mm_users: preserves everything - the mm_struct, the page tables, the
> > > > >    memory mappings, and so on
> > > > >  - mm_count: preserves the mm_struct and pgd
> > > > >
> > > > > However, there are three types of users of mm_struct:
> > > > >
> > > > > 1. users that want page tables, memory mappings and so on
> > > > > 2. users that want to preserve the pgd (for lazy TLB)
> > > > > 3. users that just want to keep the mm_struct itself around (e.g. for
> > > > >    mmget_not_zero() or __ptrace_may_access())
> > > > >
> > > > > Dropping mm_count references can be messy because dropping mm_count to
> > > > > zero deletes the pgd, which takes the pgd_lock on x86, meaning it doesn't
> > > > > work from RCU callbacks (which run in IRQ context). In those cases,
> > > > > mmdrop_async() must be used to punt the invocation of __mmdrop() to
> > > > > workqueue context.
> > > > >
> > > > > That's fine when mmdrop_async() is a rare case, but the preceding patch
> > > > > "ptrace: Keep mm around after exit_mm() for __ptrace_may_access()" makes it
> > > > > the common case; we should probably avoid punting freeing to workqueue
> > > > > context all the time if we can avoid it?
> > > > >
> > > > > To resolve this, add a third refcount that just protects the mm_struct and
> > > > > the user_ns it points to, and which can be dropped with synchronous freeing
> > > > > from (almost) any context.
> > > > >
> > > > > Signed-off-by: Jann Horn <jannh@google.com>
> > > > >  arch/x86/kernel/tboot.c    |  2 ++
> > > > >  drivers/firmware/efi/efi.c |  2 ++
> > > > >  include/linux/mm_types.h   | 13 +++++++++++--
> > > > >  include/linux/sched/mm.h   | 13 +++++++++++++
> > > > >  kernel/fork.c              | 14 ++++++++++----
> > > > >  mm/init-mm.c               |  2 ++
> > > > >  6 files changed, 40 insertions(+), 6 deletions(-)
> > > >
> > > > I think mmu notifiers and the stuff in drivers/infiniband/core/ can be
> > > > converted to this as well..
> > > >
> > > > Actually I kind of wonder if you should go the reverse and find the
> > > > few callers that care about the pgd and give them a new api with a
> > > > better name (mmget_pgd?).
> > >
> > > Yeah, that might make more sense... as long as I'm really sure about
> > > all the places I haven't changed. ^^
> > >
> > > I'll try to change it as you suggested for v2.
> >
> > Actually, no - I think it ends up being around 30 mentions of the
> > "take reference without PGD" function and around 35 mentions of the
> > "take reference with PGD" function (assuming that all the weird
> > powerpc stuff I don't understand needs the mm_context to not yet be
> > destroyed). (A decent chunk of which are all the per-arch functions
> > for starting secondary processors.) So I don't think doing it the way
> > you suggested would really make the patch(es) smaller.
> >
> > And I think that it is helpful for review purposes to have separate
> > patches for every converted site, and leave things as-is by default.
> > If the semantics change for every user that is *not* touched by the
> > patch, that makes it really easy for mistakes to slip through.
> >
> > I could try to convert more callers though?
> 
> But really, I would be happiest if I could just leave all the callers
> where both refcounts work as-is, and let people more familiar with the
> subsystems switch them over when that actually becomes necessary. Is
> that not acceptable?

Either way can work, I liked the suggestion because it suggests an
good name for the ref: 'mmget_pgd' or somesuch

What I don't like is how nonsensical the names here are becoming:
mmget/mmgrab/mm_ref

Gives no impression at the callsite what is right/wrong

Names like this:
 mmget_struct
 mmget_pgd
 mmget_tables

Make alot more sense to me..

I think this patch needs to do something about the naming..

Jason