lkml.org 
[lkml]   [2023]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v8 10/10] mm: Renumber FOLL_PIN and FOLL_GET down
On Tue, Jan 24, 2023 at 02:59:25PM +0000, David Howells wrote:
> Jason Gunthorpe <jgg@nvidia.com> wrote:
>
> > What is the 3rd state?
>
> Consider a network filesystem message generated for a direct I/O that the
> network filesystem does zerocopy on. You may have an sk_buff that has
> fragments from one or more of three different sources:
>
> (1) Fragments consisting of specifically allocated pages, such as the
> IP/UDP/TCP headers that have refs taken on them.
>
> (2) Fragments consisting of zerocopy kernel buffers that has neither refs nor
> pins belonging to the sk_buff.
>
> iov_iter_extract_pages() will not take pins when extracting from, say, an
> XARRAY-type or KVEC-type iterator. iov_iter_extract_mode() will return
> 0.
>
> (3) Fragments consisting of zerocopy user buffers that have pins taken on
> them belonging to the sk_buff.
>
> iov_iter_extract_pages() will take pins when extracting from, say, a
> UBUF-type or IOVEC-type iterator. iov_iter_extract_mode() will return
> FOLL_PIN (at the moment).
>
> So you have three states: Ref'd, pinned and no-retention.

Isn't that this:

if (cleanup_flags & PAGE_CLEANUP_NEEDED)
gup_put_folio(folio, 1, cleanup_flags & PAGE_CLEANUP_UNPIN)


?

Three states - decr get, decr pinned, do nothing?

Jason

\
 
 \ /
  Last update: 2023-03-26 23:54    [W:1.152 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site