On 8/15/19 10:32 AM, Ira Weiny wrote:
On Thu, Aug 15, 2019 at 03:35:10PM +0200, Jan Kara wrote:
quoted
On Thu 15-08-19 15:26:22, Jan Kara wrote:
quoted
On Wed 14-08-19 20:01:07, John Hubbard wrote:
quoted
On 8/14/19 5:02 PM, John Hubbard wrote:
Hold on, I *was* forgetting something: this was a two part thing, and
you're conflating the two points, but they need to remain separate and
distinct. There were:
1. FOLL_PIN is necessary because the caller is clearly in the use case that
requires it--however briefly they might be there. As Jan described it,
"Anything that gets page reference and then touches page data (e.g.
direct IO) needs the new kind of tracking so that filesystem knows
someone is messing with the page data." [1]
So when the GUP user uses MMU notifiers to stop writing to pages whenever
they are writeprotected with page_mkclean(), they don't really need page
pin - their access is then fully equivalent to any other mmap userspace
access and filesystem knows how to deal with those. I forgot out this case
when I wrote the above sentence.
So to sum up there are three cases:
1) DIO case - GUP references to pages serving as DIO buffers are needed for
relatively short time, no special synchronization with page_mkclean() or
munmap() => needs FOLL_PIN
2) RDMA case - GUP references to pages serving as DMA buffers needed for a
long time, no special synchronization with page_mkclean() or munmap()
=> needs FOLL_PIN | FOLL_LONGTERM
This case has also a special case when the pages are actually DAX. Then
the caller additionally needs file lease and additional file_pin
structure is used for tracking this usage.
3) ODP case - GUP references to pages serving as DMA buffers, MMU notifiers
used to synchronize with page_mkclean() and munmap() => normal page
references are fine.
Thanks Jan, once again, for clarifying all of this!
quoted
I want to add that I'd like to convert users in cases 1) and 2) from using
GUP to using differently named function. Users in case 3) can stay as they
are for now although ultimately I'd like to denote such use cases in a
special way as well...
Ok just to make this clear I threw up my current tree with your patches here:
https://github.com/weiny2/linux-kernel/commits/mmotm-rdmafsdax-b0-v4
I'm talking about dropping the final patch:
05fd2d3afa6b rdma/umem_odp: Use vaddr_pin_pages_remote() in ODP
The other 2 can stay. I split out the *_remote() call. We don't have a user
but I'll keep it around for a bit.
This tree is still WIP as I work through all the comments. So I've not changed
names or variable types etc... Just wanted to settle this.
Right. And now that ODP is not a user, I'll take a quick look through my other
call site conversions and see if I can find an easy one, to include here as
the first user of vaddr_pin_pages_remote(). I'll send it your way if that
works out.
thanks,
--
John Hubbard
NVIDIA