linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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 3/8] mm/gup: simplify the external interface functions and consolidate invariants
Date: Fri, 20 Jan 2023 10:58:03 -0400	[thread overview]
Message-ID: <Y8qr+3V4pByu97z8@nvidia.com> (raw)
In-Reply-To: <845c3d54-efe5-6e3a-05ca-5f419ac7d145@nvidia.com>

On Thu, Jan 19, 2023 at 06:51:18PM -0800, John Hubbard wrote:
> On 1/17/23 07:58, Jason Gunthorpe wrote:
> > The GUP family of functions have a complex, but fairly well defined, set
> > of invariants for their arguments. Currently these are sprinkled about,
> > sometimes in duplicate through many functions.
> > 
> > Internally we don't follow all the invariants that the external interface
> > has to follow, so place these checks directly at the exported
> > interface. This ensures the internal functions never reach a violated
> > invariant.
> > 
> > Remove the duplicated invariant checks.
> > 
> > The end result is to make these functions fully internal:
> >   __get_user_pages_locked()
> >   internal_get_user_pages_fast()
> >   __gup_longterm_locked()
> > 
> > And all the other functions call directly into one of these.
> > 
> > Suggested-by: John Hubbard <jhubbard@nvidia.com>
> > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> > ---
> >   mm/gup.c         | 150 +++++++++++++++++++++++------------------------
> >   mm/huge_memory.c |  10 ----
> >   2 files changed, 75 insertions(+), 85 deletions(-)
> > 
> > diff --git a/mm/gup.c b/mm/gup.c
> > index 2c833f862d0354..9e332e3f6ea8e2 100644
> > --- a/mm/gup.c
> > +++ b/mm/gup.c
> > @@ -215,7 +215,6 @@ int __must_check try_grab_page(struct page *page, unsigned int flags)
> >   {
> >   	struct folio *folio = page_folio(page);
> > -	WARN_ON_ONCE((flags & (FOLL_GET | FOLL_PIN)) == (FOLL_GET | FOLL_PIN));
> 
> try_grab_page() is declared in mm.h and is therefore potentially
> something that other subsystems could call--although they really
> shouldn't! And here, we are simply assuming that that is enough. But in
> order to be really comfortable removing this check on the basis of
> "try_grab_page() is internal to mm", I think it would help to move its
> declaration from mm.h, to mm/internal.h. Perhaps as a separate
> patch.

Yes, lets do that

> > @@ -818,7 +817,7 @@ struct page *follow_page(struct vm_area_struct *vma, unsigned long address,
> >   	if (vma_is_secretmem(vma))
> >   		return NULL;
> > -	if (foll_flags & FOLL_PIN)
> > +	if (WARN_ON_ONCE(foll_flags & FOLL_PIN))
> 
> OK, so we're slightly fortifying follow_page() checking, but
> not at the level of is_valid_gup_args(). Should this be mentioned
> in the commit description? And should the checks be more extensive?

I'd leave it, there is no reason to be too nannyish - follow_page()
isn't an exported symbol.

> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index abe6cfd92ffa0e..eaf879c835de44 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -1039,11 +1039,6 @@ struct page *follow_devmap_pmd(struct vm_area_struct *vma, unsigned long addr,
> >   	assert_spin_locked(pmd_lockptr(mm, pmd));
> > -	/* FOLL_GET and FOLL_PIN are mutually exclusive. */
> > -	if (WARN_ON_ONCE((flags & (FOLL_PIN | FOLL_GET)) ==
> > -			 (FOLL_PIN | FOLL_GET)))
> > -		return NULL;
> > -
> 
> For both follow_devmap_pmd() and follow_devmap_pud(), below, it looks like
> the following external API path is left exposed (with respect to checking
> gup flags):
> 
> do_mlock()
>   __mm_populate()
>     populate_vma_page_range()

This is in gup.c and sets the flags directly, so it is not part of the
"external interface" we should just leave it.

IMHO, the point of the checks is primarily prevent bad gup_flags from
entering gup.c, primarily from creative driver authors, not to prevent
bugs in gup.c.

Jason


  reply	other threads:[~2023-01-20 14:58 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 [this message]
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
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=Y8qr+3V4pByu97z8@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox