Re: [PATCH v7 2/8] iov_iter: Add a function to extract a page list from an iterator
From: Jan Kara
Date: Mon Jan 23 2023 - 11:11:25 EST
On Mon 23-01-23 13:38:31, David Howells wrote:
> David Hildenbrand <david@xxxxxxxxxx> wrote:
>
> > That would be the ideal case: whenever intending to access page content, use
> > FOLL_PIN instead of FOLL_GET.
> >
> > The issue that John was trying to sort out was that there are plenty of
> > callsites that do a simple put_page() instead of calling
> > unpin_user_page(). IIRC, handling that correctly in existing code -- what was
> > pinned must be released via unpin_user_page() -- was the biggest workitem.
> >
> > Not sure how that relates to your work here (that's why I was asking): if you
> > could avoid FOLL_GET, that would be great :)
>
> Well, it simplifies things a bit.
>
> I can make the new iov_iter_extract_pages() just do "pin" or "don't pin" and
> do no ref-getting at all. Things can be converted over to "unpin the pages or
> doing nothing" as they're converted over to using iov_iter_extract_pages()
> from iov_iter_get_pages*().
>
> The block bio code then only needs a single bit of state: pinned or not
> pinned.
I'm all for using only pin/unpin in the end. But you'd still need to handle
the 'put' for the intermediate time when there are still FOLL_GET users of
the bio infrastructure, wouldn't you?
> For cifs RDMA, do I need to make it pass in FOLL_LONGTERM? And does that need
> a special cleanup?
FOLL_LONGTERM doesn't need a special cleanup AFAIK. It should be used
whenever there isn't reasonably bound time after which the page is
unpinned. So in case CIFS sets up RDMA and then it is up to userspace how
long the RDMA is going to be running it should be using FOLL_LONGTERM. The
thing is that pins can block e.g. truncate for DAX inodes and so longterm
pins are not supported for DAX backed pages.
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR