Re: [RESEND PATCH 0/7] Add FOLL_LONGTERM to GUP fast and use it

Ira Weiny
2019-03-21T08:40:49Z

On Tue, Mar 19, 2019 at 03:19:30PM -0700, Andrew Morton wrote:
> On Sun, 17 Mar 2019 11:34:31 -0700 ira.weiny@intel.com wrote:
>
> > Resending after rebasing to the latest mm tree.
> >
> > HFI1, qib, and mthca, use get_user_pages_fast() due to it performance
> > advantages. These pages can be held for a significant time. But
> > get_user_pages_fast() does not protect against mapping FS DAX pages.
> >
> > Introduce FOLL_LONGTERM and use this flag in get_user_pages_fast() which
> > retains the performance while also adding the FS DAX checks. XDP has also
> > shown interest in using this functionality.[1]
> >
> > In addition we change get_user_pages() to use the new FOLL_LONGTERM flag and
> > remove the specialized get_user_pages_longterm call.
>
> It would be helpful to include your response to Christoph's question
> (http://lkml.kernel.org/r/20190220180255.GA12020@iweiny-DESK2.sc.intel.com)
> in the changelog. Because if one person was wondering about this,
> others will likely do so.
>
> We have no record of acks or reviewed-by's. At least one was missed
> (http://lkml.kernel.org/r/CAOg9mSTTcD-9bCSDfC0WRYqfVrNB4TwOzL0c4+6QXi-N_Y43Vw@mail.gmail.com),
> but that is very very partial.

That is my bad. Sorry to Mike. And I have added him.

>
> This patchset is fairly DAX-centered, but Dan wasn't cc'ed!

Agreed, I'm new to changing things which affect this many sub-systems and I
struggled with who should be CC'ed (get_maintainer.pl returned a very large
list :-(.

I fear I may have cc'ed too many people, and the wrong people apparently, so
that may be affecting the review...

So again my apologies. I don't know if Dan is going to get a chance to put a
reviewed-by on them this week but I thought I would send this note to let you
know I'm not ignoring your feedback. Just waiting a bit before resending to
hopefully get some more acks/reviewed bys.

Thanks,
Ira

>
> So ho hum. I'll scoop them up and shall make the above changes to the
> [1/n] changelog, but we still have some work to do.
>