public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: John Hubbard <jhubbard@nvidia.com>
Cc: Souptick Joarder <jrdr.linux@gmail.com>,
	alexander.deucher@amd.com, christian.koenig@amd.com,
	David1.Zhou@amd.com, daniel@ffwll.ch,
	amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/radeon: Convert get_user_pages() --> pin_user_pages()
Date: Wed, 27 May 2020 10:48:52 +0200	[thread overview]
Message-ID: <20200527084852.GN206103@phenom.ffwll.local> (raw)
In-Reply-To: <69a033cf-63b2-7da6-6a5e-a5bbc94b8afb@nvidia.com>

On Tue, May 26, 2020 at 03:57:45PM -0700, John Hubbard wrote:
> On 2020-05-26 14:00, Souptick Joarder wrote:
> > This code was using get_user_pages(), in a "Case 2" scenario
> > (DMA/RDMA), using the categorization from [1]. That means that it's
> > time to convert the get_user_pages() + release_pages() calls to
> > pin_user_pages() + unpin_user_pages() calls.
> > 
> > There is some helpful background in [2]: basically, this is a small
> > part of fixing a long-standing disconnect between pinning pages, and
> > file systems' use of those pages.
> > 
> > [1] Documentation/core-api/pin_user_pages.rst
> > 
> > [2] "Explicit pinning of user-space pages":
> >      https://lwn.net/Articles/807108/

I don't think this is a case 2 here, nor is it any of the others. Feels
like not covered at all by the doc.

radeon has a mmu notifier (might be a bit broken, but hey whatever there's
other drivers which have the same concept, but less broken). So when you
do an munmap, radeon will release the page refcount.

Which case it that?

Note that currently only amdgpu doesn't work like that for gpu dma
directly to userspace ranges, it uses hmm and afaiui doens't hold a full
page pin refcount.

Cheers, Daniel


> > 
> > Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
> > Cc: John Hubbard <jhubbard@nvidia.com>
> > 
> > Hi,
> > 
> > I'm compile tested this, but unable to run-time test, so any testing
> > help is much appriciated.
> > ---
> >   drivers/gpu/drm/radeon/radeon_ttm.c | 6 +++---
> >   1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c
> > index 5d50c9e..e927de2 100644
> > --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> > @@ -506,7 +506,7 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm)
> >   		uint64_t userptr = gtt->userptr + pinned * PAGE_SIZE;
> >   		struct page **pages = ttm->pages + pinned;
> > -		r = get_user_pages(userptr, num_pages, write ? FOLL_WRITE : 0,
> > +		r = pin_user_pages(userptr, num_pages, write ? FOLL_WRITE : 0,
> >   				   pages, NULL);
> >   		if (r < 0)
> >   			goto release_pages;
> > @@ -535,7 +535,7 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm)
> >   	kfree(ttm->sg);
> >   release_pages:
> > -	release_pages(ttm->pages, pinned);
> > +	unpin_user_pages(ttm->pages, pinned);
> >   	return r;
> >   }
> > @@ -562,7 +562,7 @@ static void radeon_ttm_tt_unpin_userptr(struct ttm_tt *ttm)
> >   			set_page_dirty(page);
> 
> 
> Maybe we also need a preceding patch, to fix the above? It should be
> set_page_dirty_lock(), rather than set_page_dirty(), unless I'm overlooking
> something (which is very possible!).
> 
> Either way, from a tunnel vision perspective of changing gup to pup, this
> looks good to me, so
> 
>     Acked-by: John Hubbard <jhubbard@nvidia.com>
> 
> 
> thanks,
> -- 
> John Hubbard
> NVIDIA
> 
> >   		mark_page_accessed(page);
> > -		put_page(page);
> > +		unpin_user_page(page);
> >   	}
> >   	sg_free_table(ttm->sg);
> > 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2020-05-27  8:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-26 21:00 [PATCH] drm/radeon: Convert get_user_pages() --> pin_user_pages() Souptick Joarder
2020-05-26 22:57 ` John Hubbard
2020-05-27  8:48   ` Daniel Vetter [this message]
2020-05-27  8:51     ` Daniel Vetter
2020-05-27 19:07       ` John Hubbard
2020-05-29  6:49         ` Souptick Joarder
2020-05-29  7:28           ` John Hubbard
2020-06-08 19:38             ` Souptick Joarder

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=20200527084852.GN206103@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=David1.Zhou@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jhubbard@nvidia.com \
    --cc=jrdr.linux@gmail.com \
    --cc=linux-kernel@vger.kernel.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