From: Jason Gunthorpe <jgg@ziepe.ca>
To: Jann Horn <jannh@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, Eric Biederman <ebiederm@xmission.com>,
Oleg Nesterov <oleg@redhat.com>,
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
Date: Fri, 16 Oct 2020 20:21:53 -0300 [thread overview]
Message-ID: <20201016232153.GD37159@ziepe.ca> (raw)
In-Reply-To: <20201016230915.1972840-4-jannh@google.com>
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?).
Jason
next prev parent reply other threads:[~2020-10-16 23:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-16 23:09 [RFC PATCH resend 0/6] mm and ptrace: Track dumpability until task is freed Jann Horn
2020-10-16 23:09 ` [RFC PATCH resend 1/6] ptrace: Keep mm around after exit_mm() for __ptrace_may_access() Jann Horn
2020-10-16 23:09 ` [RFC PATCH resend 2/6] refcount: Move refcount_t definition into linux/types.h Jann Horn
2020-10-16 23:09 ` [RFC PATCH resend 3/6] mm: Add refcount for preserving mm_struct without pgd Jann Horn
2020-10-16 23:21 ` Jason Gunthorpe [this message]
2020-10-17 0:30 ` Jann Horn
2020-11-03 2:11 ` Jann Horn
2020-11-03 3:19 ` Jann Horn
2020-11-03 13:21 ` Jason Gunthorpe
2020-11-03 19:18 ` John Hubbard
2020-10-16 23:09 ` [RFC PATCH resend 4/6] mm, oom: Use mm_ref()/mm_unref() and avoid mmdrop_async() Jann Horn
2020-10-16 23:09 ` [RFC PATCH resend 5/6] ptrace: Use mm_ref() for ->exit_mm Jann Horn
2020-10-16 23:09 ` [RFC PATCH resend 6/6] mm: remove now-unused mmdrop_async() Jann Horn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201016232153.GD37159@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.