Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH v8 10/10] mm: Renumber FOLL_PIN and FOLL_GET down | Date | Tue, 24 Jan 2023 14:59:25 +0000 |
| |
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.
David
| |