On Fri, 5 Oct 2001, Bernd Harries wrote:
> Hugh Dickins wrote:
>
> > I don't
> > know whether you're following the mmap-makes-all-pages-present
> > model (using remap_page_range), or the fault-page-by-page model
> > (supplying your own nopage function).
>
> The nopage method. In Alessandro Rubini's book (p.391) I read, that
> I can't use remap_page_range() on pages optained by get_free_page().
I just looked that up. Rubini is right that remap_page_range only
works as you'd want on reserved pages, and pages which fail the
VALID_PAGE(page) test (I'm trying to avoid saying "invalid pages"),
and there is a good reason for that. But Rubini omits to mention
mem_map_reserve, which can be used (on pages you own exclusively)
to mark a page as temporarily reserved, so remap_page_range will
then work as you'd want on it (with mem_map_unreserve to undo later).
The mem_map_reserve, remap_page_range model is commoner in drivers
than the nopage model; but it is somewhat deprecated now, Linus for
one certainly preferring the nopage model; and the VM_RESERVED vma
flag can give pages that immunity from swap_out which mem_map_reserve
also confers. You're not wrong to follow the nopage model.
> Hmm, the only thing that happens to them after munmap() is
> free_pages(). I don't access the pages anymore. But maybe some code in free_pages does? Or decrements count to -1?
I've forgotten by now what your precise symptoms were. But either
pages would be freed twice and allocated twice; or they would hit a
BUG() statement in second free or second allocation; neither good.
> > Either you should force page count 1 on each of the
> > order-0-pages before you mmap them in (and raise count to 2);
>
> by get_page(), right?
Fine; and I expect you'll need to undo it later by appropriate put_page()s.
> Ok, thanks a lot. So it's definitely insufficient how my minor 26 version handles the pages, right? If so, that's a statement I can live with.
>
> And it was never ment that I could simply mmap the upper pages to userspace directly, without 'touching' each page, was it?
Probably all the drivers which use higher order allocations are using
the older, mem_map_reserve + remap_page_range method; the reserved
bit preserves a page against freeing whatever its page count. Maybe
you're the first to use the nopage method on a higher order allocation
(or maybe not, and there are already drivers working around it).
I wouldn't claim the way it is currently is ideal design: I think
you've hit a not entirely satisfactory but easily worked around oddity,
Hugh
-
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/
This archive was generated by hypermail 2b29 : Sun Oct 07 2001 - 21:00:37 EST