...On Fri 09-08-19 15:58:13, Jan Kara wrote:
On Fri 09-08-19 10:23:07, Michal Hocko wrote:
On Fri 09-08-19 10:12:48, Vlastimil Babka wrote:
On 8/9/19 12:59 AM, John Hubbard wrote:
In principle, I'm not strongly opposed to a new FOLL flag to determine
whether a pin or an ordinary page reference will be acquired at least
as an internal implementation detail inside mm/gup.c. But I would
really like to discourage new GUP users taking just page reference as
the most clueless users (drivers) usually need a pin in the sense John
implements. So in terms of API I'd strongly prefer to deprecate GUP as
an API, provide
vaddr_pin_pages() for drivers to get their buffer pages pinned and
then for those few users who really know what they are doing (and who
are not interested in page contents) we can have APIs like
follow_page() to get a page reference from a virtual address.
Yes, going with a dedicated API sounds much better to me. Whether a
dedicated FOLL flag is used internally is not that important. I am also for
making the underlying gup to be really internal to the core kernel.
+1
I think GUP is too confusing. I've been working with the details for many months now and it continues to confuse me. :-(
My patches should be posted soon (based on mmotm) and I'll have my flame suit on so we can debate the interface.