All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: John Hubbard <jhubbard@nvidia.com>
Cc: linux-mm <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: pin_user_pages supports NULL pages arguments?
Date: Thu, 10 Feb 2022 13:17:06 -0800	[thread overview]
Message-ID: <YgWA0ghrrzHONehH@google.com> (raw)
In-Reply-To: <f79a2d94-9877-90aa-927c-d765fbdda7b2@nvidia.com>

On Thu, Feb 10, 2022 at 12:20:47PM -0800, John Hubbard wrote:
> On 2/10/22 11:29, Minchan Kim wrote:
> > On Thu, Feb 10, 2022 at 11:20:31AM -0800, John Hubbard wrote:
> > > On 2/10/22 11:17, Minchan Kim wrote:
> > > >    * pin_user_pages() - pin user pages in memory for use by other devices
> > > >    < snip >
> > > >    * @pages:      array that receives pointers to the pages pinned.
> > > >    *              Should be at least nr_pages long. Or NULL, if caller
> > > >    *              only intends to ensure the pages are faulted in.
> > > > 
> > > > pin_user_pages(,, pages = NULL, );
> > > >     gup_flags |= FOLL_PIN
> > > >     __get_user_pages_locked
> > > >       __get_user_pages
> > > >         ..
> > > >         VM_BUG_ON(!!pages != !!(gup_flags & (FOLL_GET | FOLL_PIN)));
> > > 
> > > Only FOLL_GET or FOLL_PIN are supposed to fill in the **pages array. So
> > > if a caller passes a null **pages arg, then that caller must not also
> > > set FOLL_GET or FOLL_PIN. That's what the VM_BUG_ON() is expressing.
> > 
> > Yub, but pin_user_pages adds FOLL_PIN unconditinally and the comments
> > says it supports NUU pages argument. Isn't it conflict?
> > 
> 
> Oh right, that is a conflict. The documentation should *not* say that a
> NULL **pages arg is supported. Because the whole point of the FOLL_PIN
> APIs is to actually pin struct pages. The NULL cases are only useful for
> get_user_pages*().
> 
> So removing that last sentence is appropriate, plus also looking around
> for similar documentation claims, including in pin_user_pages.rst. I
> don't see anything from a very quick scan, though.
> 
> Sending out a fix will also trigger the observation that both the
> kerneldoc headers mm/gup.c, and the writings in pin_user_pages.rst,
> could use some updating. However, it is also true that this can be
> reasonably treated as a documentation bug fix, and therefore allowed to
> be limited to just this change.
> 
> Were you going to send out a formal patch? If not, I can include it in
> an upcoming gup series, with your Reported-by tag. Up to you.

Yes, please.

Thank you, John.


      reply	other threads:[~2022-02-10 21:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-10 19:17 pin_user_pages supports NULL pages arguments? Minchan Kim
2022-02-10 19:20 ` John Hubbard
2022-02-10 19:29   ` Minchan Kim
2022-02-10 20:20     ` John Hubbard
2022-02-10 21:17       ` Minchan Kim [this message]

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=YgWA0ghrrzHONehH@google.com \
    --to=minchan@kernel.org \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --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.