Re: [PATCH v8 10/10] mm: Renumber FOLL_PIN and FOLL_GET down
From: David Howells
Date: Tue Jan 24 2023 - 10:00:26 EST
Jason Gunthorpe <jgg@xxxxxxxxxx> 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