[PATCH v6 3/5] mm/gup: Introduce memfd_pin_user_pages() for pinning memfd pages (v6)

[David Hildenbrand]

On 07.12.23 14:05, Jason Gunthorpe wrote:
> On Thu, Dec 07, 2023 at 10:44:14AM +0100, David Hildenbrand wrote:
> 
>>>> If you always want to return folios, then better name it
>>>> "memfd_pin_user_folios" (or just "memfd_pin_folios") and pass in a range
>>>> (instead of a nr_pages parameter), and somehow indicate to the caller
>>>> how many folio were in that range, and if that range was fully covered.
>>> I think it makes sense to return folios from this interface; and considering my
>>> use-case, I'd like have this API return an error if it cannot pin (or allocate)
>>> the exact number of folios the caller requested.
>>
>> Okay, then better use folios.
>>
>> Assuming a caller puts in "start = X" and gets some large folio back. How is
>> the caller supposed to know at which offset to look into that folio (IOW<
>> which subpage)? For "pages" it was obvious (you get the actual subpages),
>> but as soon as we return a large folio, some information is missing for the
>> caller.
>>
>> How can the caller figure that out?
> 
> This can only work if the memfd is required to only have full folios
> at aligned locations. Under that restriction computing the first folio
> offset is easy enough:
> 
>    folio offset = (start % folio size)
> 
> But is that true for the memfds here?

I assume folios are always naturally aligned, like:

[ 2m ][ 2m ][1m][1m][ 2m ]
^f0   ^f1   ^f2 ^f3 ^f4

If you query the range "3m -> 7m", you get back f1,f2,f3,f4 and have to 
start in the middle of the first folio with offset 1m. From there, it is
indeed simply continuing with the full folio size -- until the last 
folio, where you want to only process 1m.

folio offset = (1m % 2m)

would be correct in that case.

-- 
Cheers,

David / dhildenb