[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a428c70c-1818-a69e-a1e9-5c1a8e87be0a@redhat.com>
Date: Tue, 24 Jan 2023 15:52:52 +0100
From: David Hildenbrand <david@...hat.com>
To: David Howells <dhowells@...hat.com>
Cc: Al Viro <viro@...iv.linux.org.uk>,
Christoph Hellwig <hch@...radead.org>,
Matthew Wilcox <willy@...radead.org>,
Jens Axboe <axboe@...nel.dk>, Jan Kara <jack@...e.cz>,
Jeff Layton <jlayton@...nel.org>,
Logan Gunthorpe <logang@...tatee.com>,
linux-fsdevel@...r.kernel.org, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org, Christoph Hellwig <hch@....de>,
John Hubbard <jhubbard@...dia.com>, linux-mm@...ck.org
Subject: Re: [PATCH v8 02/10] iov_iter: Add a function to extract a page list
from an iterator
On 24.01.23 15:45, David Howells wrote:
> David Hildenbrand <david@...hat.com> wrote:
>
>> At least reduces the occurrences of FOLL_PIN :)
>
> I don't see where the problem is in letting people supply FOLL_PIN or
> FOLL_GET. Why even have pin_user_pages() and get_user_pages() since they end
> up at the same place. They should be inline wrappers, if separate functions
> at all.
There once was a proposed goal of restricting FOLL_GET to core-mm and
allowing other drivers etc. to only use FOLL_PIN. Providing
pin_user_pages() and the corresponding unpin part seemed very clean to me.
To me that makes perfect sense and will prevent any misuse once we
converted everything relevant to FOLL_PIN.
To be precise, I think we could get away in this patch set by not using
FOLL_PIN and FOLL_GET and it wouldn't really reduce readability of the
code ...
--
Thanks,
David / dhildenb
Powered by blists - more mailing lists