Re: ZERO_PAGE() vs. loadable modules in Redhat 4.4 i386 kernels ...

[Hugh Dickins]

On Wed, 27 Jun 2007, Casey Leedom wrote:
> 
>   I'm working on a driver that does a get_user_pages() for a DMA write.  We
> have a timeout on the DMA completion where we mark the pages as COW and return
> to the application so it can potentially generate more data in order to
> increase throughput, etc.  The problem is that when we traverse the
> PGT/PUD/PMD/PTE hierarchy to mark the pages, we sometime fault out when the PUD
> covering [0x80000000, 0xc0000000) comes out as zero when that entire region is
> covered by a single large malloc()'ed buffer.  This happens because
> get_user_pages() returns a reference to empty_zero_page without passing through
> the fault path when a page is backed by anonymous memory.  I put a check this
> in my driver using ZERO_PAGE() and everything is great.  Except that it doesn't
> work on 32-bit i386 Redhat 4.4 kernels because the symbol for empty_zero_page
> is not only not exported via EXPORT_SYMBOL() but has also somehow been stripped
> from the kallsyms table.  This means that I can't check for the ZERO_PAGE() in
> a module.
> 
>  Can someone suggest a better way of doing this?  Either by some subterfuge to
> get empty_zero_page or perhaps by asking the kernel to instantiate the
> PGT/PUD/PMD/PTE hierarchy for a page?  I'm sort of stuck here.  Thanks for any
> help and/or advice you can offer.

I can't speak for Red Hat 4.4; but in general, you should be passing the
write flag to get_user_pages if you're going to modify the content of
those pages, which will then allocate the hierarchy needed and break
COW where necessary.  If that doesn't suit you (e.g. it's supposed to
be a readonly area in userspace), then you proably shouldn't be using
get_user_pages at all, but letting userspace mmap your driver pages
into its space instead.  Definitely don't play empty_zero_page games.

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