linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Souptick Joarder <jrdr.linux@gmail.com>
To: John Hubbard <jhubbard@nvidia.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	 Linux-MM <linux-mm@kvack.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] mm/gup.c: Use gup_flags as parameter instead of passing write flag
Date: Tue, 19 May 2020 02:36:45 +0530	[thread overview]
Message-ID: <CAFqt6zZoFBkvkZKOc9mbGVO6_Gst+0k=wpjmXYSKvFru=HgczA@mail.gmail.com> (raw)
In-Reply-To: <975cc333-e9f4-29e4-db0e-00ea8b8a7c25@nvidia.com>

On Tue, May 19, 2020 at 2:15 AM John Hubbard <jhubbard@nvidia.com> wrote:
>
> On 2020-05-18 13:44, Souptick Joarder wrote:
> > On Tue 19 May, 2020, 1:47 AM Matthew Wilcox, <willy@infradead.org> wrote:
> >>
> >> On Tue, May 19, 2020 at 01:28:23AM +0530, Souptick Joarder wrote:
> >>> The idea is to get rid of write parameter. Instead caller will pass
> >>> FOLL_WRITE to __get_user_pages_fast(). This will not change any
> >>> functionality of the API. Once it is upstream all the callers will
> >>> be changed to pass FOLL_WRITE.
> >>
> >> Uhh ... until you change all the callers, haven't you just broken all
> >> the callers?
> >
> > All the callers have called the API with either 1 or 0.  I think, it's
> > not going to break
> > any of the callers.
>
> Maybe so, but it's still "wrong" to do that, because it only works more
> or less accidentally. That is, it works in spite of a type safety
> violation. So we don't want to do that sort of thing unless there is
> a compelling reason.
>
> In addition to that, I am at the exact moment putting together a minor
> refactoring of this function, because I need a FOLL_PIN variant:
> __pin_user_pages_fast(), as part of my work to change over a few dozen
> gup call sites to pin_user_pages*().
>
> (In fact, I was wondering whether to stick with the "write" parameter, for
> the new __pin_user_pages_fast(), or go with gup_flags. That could go either
> way: gup_flags provides a nicer API, but "write" matches the existing
> callers.)
>
> So in other words, if you do go out and change all the call sites (there only
> seem to be about 7, outside of gup.c, actually), that's going to conflict
> a little bit with what I'm doing here.
>
> So, how would you like proceed? If you want to do the full conversion
> (which really should include the call sites), it would be easier for me
> if you based it on my upcoming small patchset, which I expect to post
> shortly (later today).

Sure, I will wait for your patchset :)

As there are only 7 callers of the __get_user_pages_fast(), I prefer to do
full conversion in a single commit. But if it is not preferred way, I would go
as per feedback.

> >>
> >>> -int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
> >>> -                       struct page **pages)
> >>> +int __get_user_pages_fast(unsigned long start, int nr_pages,
> >>> +                     unsigned int gup_flags, struct page **pages)
> >>>   {
> >>>        unsigned long len, end;
> >>>        unsigned long flags;
> >>> @@ -2685,10 +2692,7 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
> >>>         * Internally (within mm/gup.c), gup fast variants must set FOLL_GET,
> >>>         * because gup fast is always a "pin with a +1 page refcount" request.
> >>>         */
> >>> -     unsigned int gup_flags = FOLL_GET;
> >>> -
> >>> -     if (write)
> >>> -             gup_flags |= FOLL_WRITE;
> >>> +     gup_flags |= FOLL_GET;
> >
>


  reply	other threads:[~2020-05-18 20:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-18 19:58 Souptick Joarder
2020-05-18 20:17 ` Matthew Wilcox
2020-05-18 20:44   ` Souptick Joarder
2020-05-18 20:45     ` John Hubbard
2020-05-18 21:06       ` Souptick Joarder [this message]
2020-05-18 21:22         ` John Hubbard

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='CAFqt6zZoFBkvkZKOc9mbGVO6_Gst+0k=wpjmXYSKvFru=HgczA@mail.gmail.com' \
    --to=jrdr.linux@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=willy@infradead.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