[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <37946.1681288867@warthog.procyon.org.uk>
Date: Wed, 12 Apr 2023 09:41:07 +0100
From: David Howells <dhowells@...hat.com>
To: David Hildenbrand <david@...hat.com>
Cc: dhowells@...hat.com, "Teterevkov, Ivan" <Ivan.Teterevkov@....com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"jhubbard@...dia.com" <jhubbard@...dia.com>,
"jack@...e.cz" <jack@...e.cz>,
"rppt@...ux.ibm.com" <rppt@...ux.ibm.com>,
"jglisse@...hat.com" <jglisse@...hat.com>,
"ira.weiny@...el.com" <ira.weiny@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Christoph Hellwig <hch@....de>,
Matthew Wilcox <willy@...radead.org>
Subject: Re: find_get_page() VS pin_user_pages()
David Hildenbrand <david@...hat.com> wrote:
> I suspect that find_get_page() is not the kind of interface you want to use
> for the purpose you describe. find_get_page() is a wrapper around
> pagecache_get_page() and seems more like a helper for implementing an fs
> (looking at the users and the fact that it only considers pages that are in
> the pagecache).
Btw, at some point we're going to need public functions to get extra pins on
pages. vmsplice() should be pinning the pages it pushes into a pipe - so all
pages in a pipe should probably be pinned - and anyone who splices a page out
of a pipe and retains it (skbuffs spring strongly to mind) should also get a
pin on the page.
So should all pages held by an skbuff be pinned rather than ref'd? I have a
patch to use the bottom two bits of an skb frag's page pointer to keep track
of whether the page it points to is ref'd, pinned or neither, but if we can
make it pin/not-pin them, I only need one bit for that.
David
Powered by blists - more mailing lists