[parisc-linux] memory management issues

[James Bottomley]

On Wed, 2007-05-02 at 16:52 -0700, Ollie Wild wrote:
> > Give me more of a clue on this one ... afterwards *who* sees the pages
> > as zero'd?  The user or the kernel ... if the user, I think it's a
> > simple coherency problem.
> 
> Ah, I should have been more clear.  I scattered a bunch of code
> similar to this throughout the kernel:
> 
>   {
>     struct page *page;
>     char * addr;
> 
>     get_user_pages(current, bprm->mm, bprm->p, 1, 0, 1, &page, NULL);
>     addr = kmap(page);
>     printk("page = %p, bprm->p = %016lx\n", page, bprm->p);
>     printk("%s: %d: \"%s\"\n", __FUNCTION__, __LINE__, addr);
>     kunmap(page);
>     put_page(page);
>   }
> 
> I observed that after the activate_mm() call, page and bprm->p were
> unchanged, but the string at addr switched from the executable name to
> the null string.

Well, it seems to be a classic case of missing flushing ... however,
because of the way you've altered the page allocation, it's incredibly
subtle.  You no longer use alloc_page() to get the page, you use
expand_stack on an anonymous vma.  The first thing this does is
immediately decohere the page because we zero it through the user
mapping before adding it to the vma.  Fortunately get_user_pages()
should make it coherent again.  however, you need to
flush_kernel_dcache_page() before kunmap() I think

> I thought that caching might play a role, so I added
> flush_dcache_page() calls after the kunmap's, but that didn't help.

It likely wouldn't ... on most architectures, flush_dcache_page() can do
strange things on non file backed areas ... although most of the time it
should call flush_kernel_dcache_page() anyway.  Try
flush_kernel_dcache_page() first and I can think further if that fails.

James