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

[Hugh Dickins <hugh@veritas.com>]

On Wed, 22 Mar 2006, Bryan O'Sullivan wrote:
> 
> ...the driver actually works just fine under 2.6.16-final.  No memory
> leaks, no funnies with page counting being wrong.

Ah, great, then I needn't look through your code, phew (no offence)!

> Under 2.6.15, what seems to be actually happening is that vmops->nopage
> is being called on each page of a 32K compound page, driving the page
> count from 1 (prior to any nopage calls) to 9.  By the time I get to my
> cleanup code, the page count has gone from 9 to 8 (whereas under 2.6.16,
> the page count has gone from 9 back to 1, where it belongs).  From this,
> it seems fairly clear that the kernel isn't decrementing the use counts
> correctly on compound pages in 2.6.15.

I'm sure Linus is right about that.  I remembered put_page_testzero
checking the wrong part of the compound page in its BUG_ON, but I'd
forgotten that release_pages ended up not freeing the compound page
at all.  Yes, 2.6.15 and its relatives do indeed leak there.

> I think my next step, rather than boring you to tears with an
> interminable slog through unfamiliar source code, is to try Linus's
> suggestion from last week of just shooting nopage in the head, and
> instead use remap_pfn_range in fops->mmap.  If the stars are aligned,
> perhaps this will give me something that works on a wide variety of
> kernels.

That may well be a good plan (given the doubts Nick raised about
whether dma_alcohol_rent gives the right kind of struct page non-slab
memory on all arches).  But one way in which the stars will be slightly
misaligned: for 2.6.14 and earlier you'll need to SetPageReserved on
each constituent of the >0-page, to get remap_pfn_range to map it (and
ClearPageReserved before freeing the >0-page); that won't do any harm
on 2.6.15 and 2.6.16 (apart from enlarging the code unnecessarily);
but we might one day remove those macros, from driver use anyway.

Hugh