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

[Casey Leedom <casey_leedom@yahoo.com>]

--- Arjan van de Ven <arjan@infradead.org> wrote:

> On Wed, 2007-06-27 at 11:53 -0700, Casey Leedom wrote:
> >   Sorry, my bad.  I'm just diving into Linux for the first time and wasn't
> > aware of the protocols.  Here's the code fragment I'm currently using:
> 
> code fragments are only very limited useful because they don't
> compile... use the power of open source and just post your entire source
> code..  (and it's open source, right?)
> 
> you sort of gave too little, we can't see how this is being used for
> example..

  Yes, it's open source -- the company I work for, Chelsio Communications,
makes it money off of the hardware and gives away all of the driver source both
under GPL and BSD licenses.  I just thought that dumping the entire driver
source would bother people.  Basically the problem is that when you call
get_user_pages() and the "write" parameter is 0, get_user_pages() calls
follow_page() with FOLL_ANON in the foll_flags parameter.  This causes
follow_page() to return a reference to empty_zero_page if the page is an
unmodified /dev/zero mapping and any portion of the PGD/PUD/PMD/PTE hierarchy
is missing.  This is all fine, but later on in our driver when we want to
follow down the PGD/PUD/PMD/PTE hierarchy to mark pages COW we fail because of
the missing mappings.

  I've thought of several solutions to this problem:

 1. If the "zero copy" DMA path comes across any /dev/zero mapped page,
    fail the zero copy path and fall back to the normal copy path.  This
    would be a minor performance loss but even worse, it requires being
    able to recognize ZERO_PAGE() which is the problem I'm battling now.

 2. Force get_user_pages() not to pass FOLL_ANON in to follow_page().
    The simplest way to do this is to pass in a non-zero "write"
    parameter but I'm leary of this because of the potential for
    side effects (lots of pages getting marked dirty, etc.)

 3. In the DMA-timeout/COW/return-to-user optimization path, if we run
    across ZERO_PAGE() then just skip to the next page since ZERO_PAGE()
    doesn't need to be marked COW.  This is our current fix but we've
    run across this inability to determine if a page we're looking at is
    the ZERO_PAGE() in an i386 32-bit Redhat 4.4 kernel ... (sigh)  This
    does work on the x86_64 kernel since empty_zero_page is an
    EXPORT_SYMBOL() under that architecture.

 4. Somehow force the PGD/PUD/PMD/PTE hierarchy to instantiate for each
    page.  Not sure how to do this ...  (I'm very new to the Linux kernel
    and working hard to catch up with everything.)

Sorry for the long drawn out explanation -- most of you probably already know
all about these paths but I just found out most of the above so I figured I
should explain what I _think_ is going on in case I've got some misconceptions.

Casey
-
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/