[parisc-linux] memory management issues

James Bottomley James.Bottomley at SteelEye.com
Thu May 3 08:53:05 MDT 2007


On Thu, 2007-05-03 at 01:11 -0700, Ollie Wild wrote:
> Thanks, James.
> 
> > 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.
> 
> This is the critical insight I was missing.  I was assuming the page
> was unaccessed prior to mapping it into the kernel.  The zeroing
> hadn't occurred to me.  Unfortunately, it looks like get_user_pages()
> doesn't make it coherent again.  Calling flush_kernel_dcache_page()
> alone fails to resolve the problem.  Calling flush_cache_page() after
> kmap() and flush_kernel_dcache_page() before kunmap() does.

No, you're perverting the use of get_user_pages() ... it's designed to
get mapping backed pages.  I already did one fix for it so the fuse
people could use it to get anonymous pages ... I have a nasty feeling
stack pages are neither file backed nor anonymous.

Really, given the page is already present and cached in user space, why
not just copy through the user mappings instead of trying to map the
pages into the kernel an then fix up coherence issues, copy then push
the coherency back to the user ... the API you want is copy_in_user().

James


> Is this a bug in get_user_pages()?  Should it be calling
> flush_cache_page() directly?
> 
> By the way, I've left my kernel running on iodine.  Try running:
> 
>     ulimit -s unlimited
>     ls -l `find /usr -type f`
> 
> Ollie




More information about the parisc-linux mailing list