From: Jason Gunthorpe <jgg@nvidia.com>
To: John Hubbard <jhubbard@nvidia.com>
Cc: Alistair Popple <apopple@nvidia.com>, linux-mm@kvack.org
Subject: Re: [PATCH 4/8] mm/gup: add an assertion that the mmap lock is locked
Date: Fri, 20 Jan 2023 11:44:12 -0400 [thread overview]
Message-ID: <Y8q2zNHvLz26pSUf@nvidia.com> (raw)
In-Reply-To: <2fca54c7-60e8-f719-ef1f-64a9cd817126@nvidia.com>
On Thu, Jan 19, 2023 at 07:08:08PM -0800, John Hubbard wrote:
> On 1/17/23 07:58, Jason Gunthorpe wrote:
> > This is always required, but we can't have a proper unguarded assertion
> > because of a shortcut in fork. So, cover as much as we can for now.
> >
> > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> > ---
> > mm/gup.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/mm/gup.c b/mm/gup.c
> > index 9e332e3f6ea8e2..d203e268793b9c 100644
> > --- a/mm/gup.c
> > +++ b/mm/gup.c
> > @@ -1350,6 +1350,14 @@ static __always_inline long __get_user_pages_locked(struct mm_struct *mm,
> > return -EAGAIN;
> > lock_dropped = true;
> > *locked = 1;
> > + } else if (flags & FOLL_PIN) {
> > + /*
> > + * The mmap lock must be held when calling this function. This
> > + * is true even for non-pin modes, but due to a shortcut in fork
> > + * not taking the lock for the new mm we cannot check this
> > + * comprehensively.
>
> I get that fork doesn't lock the newly created mm. But I'm having
> trouble finding the calling path from fork to __get_user_pages_locked()
> that leads to this comment, can you provide a hint? Both the comment
> and the commit log are rather coy about where this happens.
Hurm, so I see this did get fixed but nobody added the assertion to
gup.c :(
Jann Horn was working on this here:
https://lore.kernel.org/linux-mm/CAG48ez1-PBCdv3y8pn-Ty-b+FmBSLwDuVKFSt8h7wARLy0dF-Q@mail.gmail.com/
However, there was never any note on the mailing list what happened to
the series..
But Andrew did take:
b2767d97f5ff ("binfmt_elf: take the mmap lock around find_extend_vma()")
f3964599c22f ("mm/gup_benchmark: take the mmap lock around GUP")
Then we had this other work:
5b78ed24e8ec ("mm/pagemap: add mmap_assert_locked() annotations to find_vma*()")
Which actually added the assertion to find_vma(), which is called
unconditionally by gup.c:
__get_user_pages_locked()
__get_user_pages()
find_extend_vma()
find_vma()
So we've already had the assertion for a while now.
I'll update this commit to make it unconditional and note that it
already exists.
Thanks,
Jason
next prev parent reply other threads:[~2023-01-20 15:44 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-17 15:58 [PATCH 0/8] Simplify the external interface for GUP Jason Gunthorpe
2023-01-17 15:58 ` [PATCH 1/8] mm/gup: have internal functions get the mmap_read_lock() Jason Gunthorpe
2023-01-19 11:16 ` Mike Rapoport
2023-01-19 21:19 ` John Hubbard
2023-01-19 22:40 ` John Hubbard
2023-01-20 14:47 ` Jason Gunthorpe
2023-01-17 15:58 ` [PATCH 2/8] mm/gup: don't call __gup_longterm_locked() if FOLL_LONGTERM cannot be set Jason Gunthorpe
2023-01-19 22:24 ` John Hubbard
2023-01-17 15:58 ` [PATCH 3/8] mm/gup: simplify the external interface functions and consolidate invariants Jason Gunthorpe
2023-01-19 11:17 ` Mike Rapoport
2023-01-20 2:51 ` John Hubbard
2023-01-20 14:58 ` Jason Gunthorpe
2023-01-20 18:45 ` John Hubbard
2023-01-17 15:58 ` [PATCH 4/8] mm/gup: add an assertion that the mmap lock is locked Jason Gunthorpe
2023-01-20 3:08 ` John Hubbard
2023-01-20 15:44 ` Jason Gunthorpe [this message]
2023-01-17 15:58 ` [PATCH 5/8] mm/gup: add FOLL_UNLOCK Jason Gunthorpe
2023-01-19 11:18 ` Mike Rapoport
2023-01-20 13:45 ` Jason Gunthorpe
2023-01-20 14:58 ` Mike Rapoport
2023-01-20 19:02 ` John Hubbard
2023-01-23 11:37 ` David Hildenbrand
2023-01-23 17:58 ` Jason Gunthorpe
2023-01-23 22:22 ` John Hubbard
2023-01-24 13:08 ` David Hildenbrand
2023-01-17 15:58 ` [PATCH 6/8] mm/gup: make locked never NULL in the internal GUP functions Jason Gunthorpe
2023-01-20 19:19 ` John Hubbard
2023-01-21 0:21 ` Jason Gunthorpe
2023-01-23 11:35 ` David Hildenbrand
2023-01-23 12:44 ` Jason Gunthorpe
2023-01-23 12:59 ` David Hildenbrand
2023-01-23 18:07 ` Jason Gunthorpe
2023-01-17 15:58 ` [PATCH 7/8] mm/gup: remove pin_user_pages_fast_only() Jason Gunthorpe
2023-01-20 19:23 ` John Hubbard
2023-01-23 11:31 ` David Hildenbrand
2023-01-17 15:58 ` [PATCH 8/8] mm/gup: make get_user_pages_fast_only() return the common return value Jason Gunthorpe
2023-01-20 19:27 ` John Hubbard
2023-01-23 11:33 ` David Hildenbrand
2023-01-19 11:18 ` [PATCH 0/8] Simplify the external interface for GUP Mike Rapoport
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=Y8q2zNHvLz26pSUf@nvidia.com \
--to=jgg@nvidia.com \
--cc=apopple@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=linux-mm@kvack.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.