Messages in this thread | | | Date | Tue, 24 Jan 2023 11:06:49 -0400 | From | Jason Gunthorpe <> | Subject | Re: [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
| |