Re: [PATCH 09/19] drm/via: set FOLL_PIN via pin_user_pages_fast()

John Hubbard
2019-11-05T18:16:36Z

On 11/5/19 1:49 AM, Daniel Vetter wrote:
> On Mon, Nov 04, 2019 at 11:20:38AM -0800, John Hubbard wrote:
>> On 11/4/19 10:10 AM, Daniel Vetter wrote:
>>> On Thu, Oct 31, 2019 at 04:36:28PM -0700, Ira Weiny wrote:
>>>> On Wed, Oct 30, 2019 at 03:49:20PM -0700, John Hubbard wrote:
>>>>> Convert drm/via to use the new pin_user_pages_fast() call, which sets
>>>>> FOLL_PIN. Setting FOLL_PIN is now required for code that requires
>>>>> tracking of pinned pages, and therefore for any code that calls
>>>>> put_user_page().
>>>>>
>>>>
>>>> Reviewed-by: Ira Weiny <ira.weiny@intel.com>
>>>
>>> No one's touching the via driver anymore, so feel free to merge this
>>> through whatever tree suits best (aka I'll drop this on the floor and
>>> forget about it now).
>>>
>>> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>
>>
>> OK, great. Yes, in fact, I'm hoping Andrew can just push the whole series
>> in through the mm tree, because that would allow it to be done in one
>> shot, in 5.5
>
> btw is there more? We should have a bunch more userptr stuff in various
> drivers, so was really surprised that drm/via is the only thing in your
> series.

There is more, but:

1) Fortunately, the opt-in nature of FOLL_PIN allows converting a few call
sites at a time. And so this patchset limits itself to converting the bare
minimum required to get started, which is:

a) calls sites that have already been converted to put_user_page(),
and

b) call sites that set FOLL_LONGTERM.

So yes, follow-up patches will be required. This is not everything.
In fact, if I can fix this series up quickly enough that it makes it into
mmotm soon-ish, then there may be time to get some follow-patches on top
of it, in time for 5.5.

2) If I recall correctly, Jerome and maybe others are working to remove
as many get_user_pages() callers from drm as possible, and instead use
a non-pinned page approach, with mmu notifiers instead. I'm not sure of
the exact status of that work, but I see that etnaviv, amdgpu, i915, and
radeon still call gup() in linux-next.

Anyway, some of those call sites will disappear. Although I'd expect a
few to remain, because I doubt the simpler GPUs can support page faulting.

thanks,

John Hubbard
NVIDIA