Re: [PATCH 10 of 20] ipath - support for userspace apps using core driver

[Hugh Dickins <hugh@veritas.com>]

On Wed, 15 Mar 2006, Andrew Morton wrote:
> Roland Dreier <rdreier@cisco.com> wrote:
> 
> > Or maybe it's just simpler to use vm_insert_page() in the .mmap method
> > and not try to be fancy with .nopage?
> 
> One would need to work out what to do with these pages when they're shared,
> after a fork - a ->nopage() handler would still be needed there, assuming
> the VMA is marked VM_DONTCOPY.  Because we don't copy all the pte's on a
> VM_DONTCOPY vma at fork()-time.  (I think we _could_, but we don't)

Misapprehension of VM_DONTCOPY addressed in another reply.

> vm_insert_page() mucks around with rmap-named functions which don't
> actually do rmap and sports apparently-incorrect comments wrt
> PageReserved().  I don't know how well-cared-for it is...

It does seem to have four users intree now, so I hope it works.

It was a byproduct of when Linus thought he could get away with
limiting remap_pfn_range, in ways that later proved unsustainable.
It's a bit surplus to requirements now, but does have those users.

I'm not keen on it, because I think most drivers actually
want something slightly different (a remap_vmalloc_pages or a
remap_highorder_page).  But that will emerge later on, in that
fabled time when I go remove the SetPageReserveds from drivers.

Yes, there are some out-of-date comments thereabouts: I did correct
them once, but in one of those patches that Linus rejected.

insert_page does a page_add_file_rmap to bump the mapcount, yes;
but whether we ever "reverse map" from page to pte depends on other
things (page->mapping and prio_tree) certainly not set here, and
probably not (indeed, hopefully not!) done by any vm_insert_page
caller.  That criticism applies to all the page_add_rmaps and
page_remove_rmaps: we carried over the name from pte_chain days,
but the only thing that gets added or removed there now is "1".

Hugh