* [PATCH 1/2] drm/etnaviv: Use FOLL_FORCE for userptr @ 2021-03-01 9:52 Daniel Vetter 2021-03-01 9:52 ` [PATCH 2/2] drm/etnaviv: User FOLL_LONGTERM in userptr Daniel Vetter ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: Daniel Vetter @ 2021-03-01 9:52 UTC (permalink / raw) To: DRI Development Cc: John Hubbard, Daniel Vetter, etnaviv, stable, Russell King, Daniel Vetter Nothing checks userptr.ro except this call to pup_fast, which means there's nothing actually preventing userspace from writing to this. Which means you can just read-only mmap any file you want, userptr it and then write to it with the gpu. Not good. The right way to handle this is FOLL_WRITE | FOLL_FORCE, which will break any COW mappings and update tracking for MAY_WRITE mappings so there's no exploit and the vm isn't confused about what's going on. For any legit use case there's no difference from what userspace can observe and do. Cc: stable@vger.kernel.org Cc: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: etnaviv@lists.freedesktop.org --- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c b/drivers/gpu/drm/etnaviv/etnaviv_gem.c index 6d38c5c17f23..a9e696d05b33 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c @@ -689,7 +689,7 @@ static int etnaviv_gem_userptr_get_pages(struct etnaviv_gem_object *etnaviv_obj) struct page **pages = pvec + pinned; ret = pin_user_pages_fast(ptr, num_pages, - !userptr->ro ? FOLL_WRITE : 0, pages); + FOLL_WRITE | FOLL_FORCE, pages); if (ret < 0) { unpin_user_pages(pvec, pinned); kvfree(pvec); -- 2.30.0 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH 2/2] drm/etnaviv: User FOLL_LONGTERM in userptr 2021-03-01 9:52 [PATCH 1/2] drm/etnaviv: Use FOLL_FORCE for userptr Daniel Vetter @ 2021-03-01 9:52 ` Daniel Vetter 2021-03-01 10:26 ` John Hubbard 2021-03-01 10:28 ` [PATCH 1/2] drm/etnaviv: Use FOLL_FORCE for userptr Lucas Stach 2021-03-19 19:09 ` Daniel Vetter 2 siblings, 1 reply; 8+ messages in thread From: Daniel Vetter @ 2021-03-01 9:52 UTC (permalink / raw) To: DRI Development Cc: John Hubbard, Daniel Vetter, etnaviv, Russell King, Daniel Vetter There's no mmu notifier or anything like that, releasing this pin is entirely up to userspace. Hence FOLL_LONGTERM. No cc: stable for this patch since a lot of the infrastructure around FOLL_LONGETRM (like not allowing it for pages currently sitting in ZONE_MOVEABLE before they're migrated) is still being worked on. So not big benefits yet. Cc: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: etnaviv@lists.freedesktop.org --- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c b/drivers/gpu/drm/etnaviv/etnaviv_gem.c index a9e696d05b33..db69f19ab5bc 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c @@ -689,7 +689,8 @@ static int etnaviv_gem_userptr_get_pages(struct etnaviv_gem_object *etnaviv_obj) struct page **pages = pvec + pinned; ret = pin_user_pages_fast(ptr, num_pages, - FOLL_WRITE | FOLL_FORCE, pages); + FOLL_WRITE | FOLL_FORCE | FOLL_LONGTERM, + pages); if (ret < 0) { unpin_user_pages(pvec, pinned); kvfree(pvec); -- 2.30.0 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] drm/etnaviv: User FOLL_LONGTERM in userptr 2021-03-01 9:52 ` [PATCH 2/2] drm/etnaviv: User FOLL_LONGTERM in userptr Daniel Vetter @ 2021-03-01 10:26 ` John Hubbard 2021-03-19 19:16 ` Daniel Vetter 0 siblings, 1 reply; 8+ messages in thread From: John Hubbard @ 2021-03-01 10:26 UTC (permalink / raw) To: Daniel Vetter, DRI Development; +Cc: Daniel Vetter, Russell King, etnaviv On 3/1/21 01:52, Daniel Vetter wrote: > There's no mmu notifier or anything like that, releasing this pin is > entirely up to userspace. Hence FOLL_LONGTERM. > > No cc: stable for this patch since a lot of the infrastructure around > FOLL_LONGETRM (like not allowing it for pages currently sitting in ^FOLL_LONGTERM > ZONE_MOVEABLE before they're migrated) is still being worked on. So > not big benefits yet. Yes. Great write-up, that's very clear, and it's exactly where we're at. Reviewed-by: John Hubbard <jhubbard@nvidia.com> thanks, -- John Hubbard NVIDIA > > Cc: John Hubbard <jhubbard@nvidia.com> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > Cc: Lucas Stach <l.stach@pengutronix.de> > Cc: Russell King <linux+etnaviv@armlinux.org.uk> > Cc: Christian Gmeiner <christian.gmeiner@gmail.com> > Cc: etnaviv@lists.freedesktop.org > --- > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c b/drivers/gpu/drm/etnaviv/etnaviv_gem.c > index a9e696d05b33..db69f19ab5bc 100644 > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c > @@ -689,7 +689,8 @@ static int etnaviv_gem_userptr_get_pages(struct etnaviv_gem_object *etnaviv_obj) > struct page **pages = pvec + pinned; > > ret = pin_user_pages_fast(ptr, num_pages, > - FOLL_WRITE | FOLL_FORCE, pages); > + FOLL_WRITE | FOLL_FORCE | FOLL_LONGTERM, > + pages); > if (ret < 0) { > unpin_user_pages(pvec, pinned); > kvfree(pvec); > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] drm/etnaviv: User FOLL_LONGTERM in userptr 2021-03-01 10:26 ` John Hubbard @ 2021-03-19 19:16 ` Daniel Vetter 0 siblings, 0 replies; 8+ messages in thread From: Daniel Vetter @ 2021-03-19 19:16 UTC (permalink / raw) To: John Hubbard Cc: Daniel Vetter, etnaviv, DRI Development, Russell King, Daniel Vetter On Mon, Mar 01, 2021 at 02:26:01AM -0800, John Hubbard wrote: > On 3/1/21 01:52, Daniel Vetter wrote: > > There's no mmu notifier or anything like that, releasing this pin is > > entirely up to userspace. Hence FOLL_LONGTERM. > > > > No cc: stable for this patch since a lot of the infrastructure around > > FOLL_LONGETRM (like not allowing it for pages currently sitting in > > ^FOLL_LONGTERM > > > ZONE_MOVEABLE before they're migrated) is still being worked on. So > > not big benefits yet. > > Yes. Great write-up, that's very clear, and it's exactly where we're at. > > Reviewed-by: John Hubbard <jhubbard@nvidia.com> Both patches pushed to drm-misc-fixes. 2nd one maybe not required there, but easier due to conflicts. Thanks for the review. -Daniel > > > thanks, > -- > John Hubbard > NVIDIA > > > > > Cc: John Hubbard <jhubbard@nvidia.com> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > Cc: Lucas Stach <l.stach@pengutronix.de> > > Cc: Russell King <linux+etnaviv@armlinux.org.uk> > > Cc: Christian Gmeiner <christian.gmeiner@gmail.com> > > Cc: etnaviv@lists.freedesktop.org > > --- > > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c b/drivers/gpu/drm/etnaviv/etnaviv_gem.c > > index a9e696d05b33..db69f19ab5bc 100644 > > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c > > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c > > @@ -689,7 +689,8 @@ static int etnaviv_gem_userptr_get_pages(struct etnaviv_gem_object *etnaviv_obj) > > struct page **pages = pvec + pinned; > > ret = pin_user_pages_fast(ptr, num_pages, > > - FOLL_WRITE | FOLL_FORCE, pages); > > + FOLL_WRITE | FOLL_FORCE | FOLL_LONGTERM, > > + pages); > > if (ret < 0) { > > unpin_user_pages(pvec, pinned); > > kvfree(pvec); > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] drm/etnaviv: Use FOLL_FORCE for userptr 2021-03-01 9:52 [PATCH 1/2] drm/etnaviv: Use FOLL_FORCE for userptr Daniel Vetter 2021-03-01 9:52 ` [PATCH 2/2] drm/etnaviv: User FOLL_LONGTERM in userptr Daniel Vetter @ 2021-03-01 10:28 ` Lucas Stach 2021-03-01 13:50 ` Daniel Vetter 2021-03-19 19:09 ` Daniel Vetter 2 siblings, 1 reply; 8+ messages in thread From: Lucas Stach @ 2021-03-01 10:28 UTC (permalink / raw) To: Daniel Vetter, DRI Development Cc: John Hubbard, etnaviv, stable, Russell King, Daniel Vetter Am Montag, dem 01.03.2021 um 10:52 +0100 schrieb Daniel Vetter: > Nothing checks userptr.ro except this call to pup_fast, which means > there's nothing actually preventing userspace from writing to this. > Which means you can just read-only mmap any file you want, userptr it > and then write to it with the gpu. Not good. I agree about the "not good" part. > The right way to handle this is FOLL_WRITE | FOLL_FORCE, which will > break any COW mappings and update tracking for MAY_WRITE mappings so > there's no exploit and the vm isn't confused about what's going on. > For any legit use case there's no difference from what userspace can > observe and do. This however seems pretty heavy handed. Does this mean we do a full COW cycle of the userpages on BO creation? This most likely kills a lot of the performance benefits that one might seek by using userptr. If that's the case I might still take this patch for stable, but then we should rather just disallow writable GPU mappings to this BO. Regards, Lucas > > Cc: stable@vger.kernel.org > Cc: John Hubbard <jhubbard@nvidia.com> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > Cc: Lucas Stach <l.stach@pengutronix.de> > Cc: Russell King <linux+etnaviv@armlinux.org.uk> > Cc: Christian Gmeiner <christian.gmeiner@gmail.com> > Cc: etnaviv@lists.freedesktop.org > --- > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c b/drivers/gpu/drm/etnaviv/etnaviv_gem.c > index 6d38c5c17f23..a9e696d05b33 100644 > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c > @@ -689,7 +689,7 @@ static int etnaviv_gem_userptr_get_pages(struct etnaviv_gem_object *etnaviv_obj) > struct page **pages = pvec + pinned; > > > > > > > > > ret = pin_user_pages_fast(ptr, num_pages, > - !userptr->ro ? FOLL_WRITE : 0, pages); > + FOLL_WRITE | FOLL_FORCE, pages); > if (ret < 0) { > unpin_user_pages(pvec, pinned); > kvfree(pvec); _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] drm/etnaviv: Use FOLL_FORCE for userptr 2021-03-01 10:28 ` [PATCH 1/2] drm/etnaviv: Use FOLL_FORCE for userptr Lucas Stach @ 2021-03-01 13:50 ` Daniel Vetter 0 siblings, 0 replies; 8+ messages in thread From: Daniel Vetter @ 2021-03-01 13:50 UTC (permalink / raw) To: Lucas Stach Cc: John Hubbard, The etnaviv authors, stable, DRI Development, Russell King, Daniel Vetter On Mon, Mar 1, 2021 at 11:28 AM Lucas Stach <l.stach@pengutronix.de> wrote: > > Am Montag, dem 01.03.2021 um 10:52 +0100 schrieb Daniel Vetter: > > Nothing checks userptr.ro except this call to pup_fast, which means > > there's nothing actually preventing userspace from writing to this. > > Which means you can just read-only mmap any file you want, userptr it > > and then write to it with the gpu. Not good. > > I agree about the "not good" part. > > > The right way to handle this is FOLL_WRITE | FOLL_FORCE, which will > > break any COW mappings and update tracking for MAY_WRITE mappings so > > there's no exploit and the vm isn't confused about what's going on. > > For any legit use case there's no difference from what userspace can > > observe and do. > > This however seems pretty heavy handed. Does this mean we do a full COW > cycle of the userpages on BO creation? This most likely kills a lot of > the performance benefits that one might seek by using userptr. If > that's the case I might still take this patch for stable, but then we > should rather just disallow writable GPU mappings to this BO. That's not what's happening. If the mmap is writeable already (like any malloc'ed area, and anything you might vacuum up with Xshm), then FOLL_FORCE does nothing. The difference only happens when the current mmap region (or some of the pte at least) is read-only. Then: - for MAP_SHARED with the VM_MAYWRITE flag set, we simply adjust some book-keeping (no copying of pages), so that the core mm doesn't get confused about the potentially changed pages contents due to gpu writes. Without this you could corrupt fs state (e.g. when the fs checksums file contents or does in-place mmap and stuff like that). - for MAP_PRIVATE we force the CoW. Just don't do userptr on these, really, it doesn't make much sense anyway. And note again, if the mapping is currently writeable, then there's no copying going on, this is only when the mmap/pte is currently read-only. This is the "let's overwrite libc.so" attack vector :-) So really in practice nothing should happen here aside from plugging the "not good" part. Note that on recent kernels the CoW breaking on fork() happens irrespective of FOLL_FORCE or not once you have the mapping established. So if you do a lot of userptr on MAP_PRIVATE already and applications are using fork(), then you're already suffering big time (since 5.10 or so iirc, John probably knows the exact commit without looking). -Daniel > Regards, > Lucas > > > > > Cc: stable@vger.kernel.org > > Cc: John Hubbard <jhubbard@nvidia.com> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > Cc: Lucas Stach <l.stach@pengutronix.de> > > Cc: Russell King <linux+etnaviv@armlinux.org.uk> > > Cc: Christian Gmeiner <christian.gmeiner@gmail.com> > > Cc: etnaviv@lists.freedesktop.org > > --- > > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c b/drivers/gpu/drm/etnaviv/etnaviv_gem.c > > index 6d38c5c17f23..a9e696d05b33 100644 > > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c > > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c > > @@ -689,7 +689,7 @@ static int etnaviv_gem_userptr_get_pages(struct etnaviv_gem_object *etnaviv_obj) > > struct page **pages = pvec + pinned; > > > > > > > > > > > > > > > > > > ret = pin_user_pages_fast(ptr, num_pages, > > - !userptr->ro ? FOLL_WRITE : 0, pages); > > + FOLL_WRITE | FOLL_FORCE, pages); > > if (ret < 0) { > > unpin_user_pages(pvec, pinned); > > kvfree(pvec); > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] drm/etnaviv: Use FOLL_FORCE for userptr 2021-03-01 9:52 [PATCH 1/2] drm/etnaviv: Use FOLL_FORCE for userptr Daniel Vetter 2021-03-01 9:52 ` [PATCH 2/2] drm/etnaviv: User FOLL_LONGTERM in userptr Daniel Vetter 2021-03-01 10:28 ` [PATCH 1/2] drm/etnaviv: Use FOLL_FORCE for userptr Lucas Stach @ 2021-03-19 19:09 ` Daniel Vetter 2021-03-19 19:13 ` Lucas Stach 2 siblings, 1 reply; 8+ messages in thread From: Daniel Vetter @ 2021-03-19 19:09 UTC (permalink / raw) To: DRI Development Cc: John Hubbard, Daniel Vetter, etnaviv, stable, Russell King, Daniel Vetter On Mon, Mar 01, 2021 at 10:52:53AM +0100, Daniel Vetter wrote: > Nothing checks userptr.ro except this call to pup_fast, which means > there's nothing actually preventing userspace from writing to this. > Which means you can just read-only mmap any file you want, userptr it > and then write to it with the gpu. Not good. > > The right way to handle this is FOLL_WRITE | FOLL_FORCE, which will > break any COW mappings and update tracking for MAY_WRITE mappings so > there's no exploit and the vm isn't confused about what's going on. > For any legit use case there's no difference from what userspace can > observe and do. > > Cc: stable@vger.kernel.org > Cc: John Hubbard <jhubbard@nvidia.com> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > Cc: Lucas Stach <l.stach@pengutronix.de> > Cc: Russell King <linux+etnaviv@armlinux.org.uk> > Cc: Christian Gmeiner <christian.gmeiner@gmail.com> > Cc: etnaviv@lists.freedesktop.org Can I please have an ack on this so I can apply it? It's stuck. Thanks, Daniel > --- > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c b/drivers/gpu/drm/etnaviv/etnaviv_gem.c > index 6d38c5c17f23..a9e696d05b33 100644 > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c > @@ -689,7 +689,7 @@ static int etnaviv_gem_userptr_get_pages(struct etnaviv_gem_object *etnaviv_obj) > struct page **pages = pvec + pinned; > > ret = pin_user_pages_fast(ptr, num_pages, > - !userptr->ro ? FOLL_WRITE : 0, pages); > + FOLL_WRITE | FOLL_FORCE, pages); > if (ret < 0) { > unpin_user_pages(pvec, pinned); > kvfree(pvec); > -- > 2.30.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] drm/etnaviv: Use FOLL_FORCE for userptr 2021-03-19 19:09 ` Daniel Vetter @ 2021-03-19 19:13 ` Lucas Stach 0 siblings, 0 replies; 8+ messages in thread From: Lucas Stach @ 2021-03-19 19:13 UTC (permalink / raw) To: Daniel Vetter, DRI Development Cc: John Hubbard, Daniel Vetter, etnaviv, stable, Russell King, Daniel Vetter Am Freitag, dem 19.03.2021 um 20:09 +0100 schrieb Daniel Vetter: > On Mon, Mar 01, 2021 at 10:52:53AM +0100, Daniel Vetter wrote: > > Nothing checks userptr.ro except this call to pup_fast, which means > > there's nothing actually preventing userspace from writing to this. > > Which means you can just read-only mmap any file you want, userptr it > > and then write to it with the gpu. Not good. > > > > The right way to handle this is FOLL_WRITE | FOLL_FORCE, which will > > break any COW mappings and update tracking for MAY_WRITE mappings so > > there's no exploit and the vm isn't confused about what's going on. > > For any legit use case there's no difference from what userspace can > > observe and do. > > > > Cc: stable@vger.kernel.org > > Cc: John Hubbard <jhubbard@nvidia.com> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > Cc: Lucas Stach <l.stach@pengutronix.de> > > Cc: Russell King <linux+etnaviv@armlinux.org.uk> > > Cc: Christian Gmeiner <christian.gmeiner@gmail.com> > > Cc: etnaviv@lists.freedesktop.org > > Can I please have an ack on this so I can apply it? It's stuck. Reviewed-by: Lucas Stach <l.stach@pengutronix.de> > Thanks, Daniel > > > --- > > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c b/drivers/gpu/drm/etnaviv/etnaviv_gem.c > > index 6d38c5c17f23..a9e696d05b33 100644 > > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c > > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c > > @@ -689,7 +689,7 @@ static int etnaviv_gem_userptr_get_pages(struct etnaviv_gem_object *etnaviv_obj) > > struct page **pages = pvec + pinned; > > > > > > > > > > ret = pin_user_pages_fast(ptr, num_pages, > > - !userptr->ro ? FOLL_WRITE : 0, pages); > > + FOLL_WRITE | FOLL_FORCE, pages); > > if (ret < 0) { > > unpin_user_pages(pvec, pinned); > > kvfree(pvec); > > -- > > 2.30.0 > > > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-03-19 19:16 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-01 9:52 [PATCH 1/2] drm/etnaviv: Use FOLL_FORCE for userptr Daniel Vetter 2021-03-01 9:52 ` [PATCH 2/2] drm/etnaviv: User FOLL_LONGTERM in userptr Daniel Vetter 2021-03-01 10:26 ` John Hubbard 2021-03-19 19:16 ` Daniel Vetter 2021-03-01 10:28 ` [PATCH 1/2] drm/etnaviv: Use FOLL_FORCE for userptr Lucas Stach 2021-03-01 13:50 ` Daniel Vetter 2021-03-19 19:09 ` Daniel Vetter 2021-03-19 19:13 ` Lucas Stach
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).