From: Jason Gunthorpe <jgg@ziepe.ca>
To: Jann Horn <jannh@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
"Eric W . Biederman" <ebiederm@xmission.com>,
Michel Lespinasse <walken@google.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>
Subject: Re: [PATCH 4/4] mm/gup: Assert that the mmap lock is held in __get_user_pages()
Date: Wed, 30 Sep 2020 09:32:17 -0300 [thread overview]
Message-ID: <20200930123217.GD9916@ziepe.ca> (raw)
In-Reply-To: <CAG48ez1GM==OnHpS=ghqZNJPn02FCDUEHc7GQmGRMXUD_aKudg@mail.gmail.com>
On Tue, Sep 29, 2020 at 06:20:01PM -0700, Jann Horn wrote:
> After having cleaned up all GUP callers (except for the atomisp staging
> driver, which currently gets mmap locking completely wrong [1]) to always
> ensure that they hold the mmap lock when calling into GUP (unless the mm is
> not yet globally visible), add an assertion to make sure it stays that way
> going forward.
>
> [1] https://lore.kernel.org/lkml/CAG48ez3tZAb9JVhw4T5e-i=h2_DUZxfNRTDsagSRCVazNXx5qA@mail.gmail.com/
>
> Signed-off-by: Jann Horn <jannh@google.com>
> ---
> mm/gup.c | 2 ++
> 1 file changed, 2 insertions(+)
I'm happy to see this, I have observed many cases of missing locking
here.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Thanks,
Jason
next prev parent reply other threads:[~2020-09-30 12:32 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200930011944.19869-1-jannh@google.com>
2020-09-30 1:20 ` [PATCH 2/4] binfmt_elf: Take the mmap lock around find_extend_vma() Jann Horn
2020-09-30 1:20 ` Jann Horn
2020-09-30 23:22 ` Michel Lespinasse
2020-09-30 23:22 ` Michel Lespinasse
2020-09-30 1:20 ` [PATCH 3/4] mmap locking API: Don't check locking if the mm isn't live yet Jann Horn
2020-09-30 1:20 ` Jann Horn
2020-09-30 12:30 ` Jason Gunthorpe
2020-09-30 12:50 ` Jann Horn
2020-09-30 12:50 ` Jann Horn
2020-09-30 20:14 ` Jann Horn
2020-09-30 20:14 ` Jann Horn
2020-09-30 23:26 ` Jason Gunthorpe
2020-09-30 23:51 ` Jann Horn
2020-09-30 23:51 ` Jann Horn
2020-10-01 19:15 ` Jason Gunthorpe
2020-10-01 20:16 ` Jann Horn
2020-10-01 20:16 ` Jann Horn
2020-10-01 23:41 ` Jason Gunthorpe
2020-10-01 23:55 ` Jann Horn
2020-10-01 23:55 ` Jann Horn
2020-09-30 23:42 ` Michel Lespinasse
2020-09-30 23:42 ` Michel Lespinasse
2020-09-30 1:20 ` [PATCH 4/4] mm/gup: Assert that the mmap lock is held in __get_user_pages() Jann Horn
2020-09-30 1:20 ` Jann Horn
2020-09-30 12:32 ` Jason Gunthorpe [this message]
2020-09-30 23:24 ` Michel Lespinasse
2020-09-30 23:24 ` Michel Lespinasse
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=20200930123217.GD9916@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mchehab@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=walken@google.com \
/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.