Messages in this thread | | | Date | Tue, 16 Apr 2019 15:57:35 -0400 | From | Jerome Glisse <> | Subject | Re: [PATCH v1 00/15] Keep track of GUPed pages in fs and block |
| |
On Tue, Apr 16, 2019 at 10:28:40PM +0300, Boaz Harrosh wrote: > On 16/04/19 22:12, Dan Williams wrote: > > On Tue, Apr 16, 2019 at 11:59 AM Kent Overstreet > > <kent.overstreet@gmail.com> wrote: > <> > > This all reminds of the failed attempt to teach the block layer to > > operate without pages: > > > > https://lore.kernel.org/lkml/20150316201640.33102.33761.stgit@dwillia2-desk3.amr.corp.intel.com/ > > > > Exactly why I want to make sure it is just a [pointer | flag] and not any kind of pfn > type. Let us please not go there again? > > >> > >> Question though - why do we need a flag for whether a page is a GUP page or not? > >> Couldn't the needed information just be determined by what range the pfn is not > >> (i.e. whether or not it has a struct page associated with it)? > > > > That amounts to a pfn_valid() check which is a bit heavier than if we > > can store a flag in the bv_pfn entry directly. > > > > I'd say create a new PFN_* flag, and make bv_pfn a 'pfn_t' rather than > > an 'unsigned long'. > > > > No, please please not. This is not a pfn and not a pfn_t. It is a page-ptr > and a flag that says where/how to put_page it. IE I did a GUP on this page > please do a PUP on this page instead of regular put_page. So no where do I mean > pfn or pfn_t in this code. Then why? > > > That said, I'm still in favor of Jan's proposal to just make the > > bv_page semantics uniform. Otherwise we're complicating this core > > infrastructure for some yet to be implemented GPU memory management > > capabilities with yet to be determined value. Circle back when that > > value is clear, but in the meantime fix the GUP bug. > > > > I agree there are simpler ways to solve the bugs at hand then > to system wide separate get_user_page from get_page and force all put_user > callers to remember what to do. Is there some Document explaining the > all design of where this is going? >
A very long thread on this:
https://lkml.org/lkml/2018/12/3/1128
especialy all the reply to this first one
There is also:
https://lkml.org/lkml/2019/3/26/1395 https://lwn.net/Articles/753027/
Cheers, Jérôme
| |