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

["Bryan O'Sullivan" <bos@pathscale.com>]

On Wed, 2006-03-15 at 21:38 -0800, Andrew Morton wrote:

> >         Bad page state at __free_pages_ok (in process 'mpi_hello', page ffff8100020e2f88)
> >         flags:0x0100000000000804 mapping:0000000000000000 mapcount:0 count:0 (Not tainted)
> 
> Someone left PG_private set on this page (!)

I can't tell you how that happened.  I'm certainly not explicitly
setting it anywhere.  Apart from PG_reserved (now gone, as seen above),
I don't touch any page flags.

> Pages which the driver owns should be owned by the, umm, driver.  The
> driver allocates them, tracks their status, does a put_page() when it's
> done with them.

This is more or less what we're doing now.  Except we're not doing a
get_page after dma_alloc_coherent, and vmops->nopage is doing a
get_page.  Reading between the lines, I guess the driver should be doing
a get_page right after the allocation, and a put_page before it does the
free?  This matches my mental model at least, but it seems that my model
is a bit mental.

> If the process "owns" these pages then they get allocated in ->nopage and
> they get freed in exit(), munmap(), mremap(), etc.

OK, we don't have any cases like this.

> If you have pages which are created by ->nopage() but which are supposed to
> be shared across forks (the VMA should use VM_DONTCOPY|VM_SHARED) then each
> time a new process starts accessing these already-existing pages it'll take
> a minor fault.

And we don't have any cases like this either.  All of these mappings are
per-process, not to be shared across fork or clone.

Thanks,

	<b

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/