[parisc-linux] Re: RFC: mmap patch

[John Marvin]

>
> Yes, the {copy,clear}_user_page() thing is an optimization for
> handling of cache alias issues wrt. anonymous pages.
>
I already implemented that solution on the parisc port. Well actually
only half :-). I implemented both the copy and clear user page optimizations,
but later on disabled the copy_user_page solution. I can't remember the
exact details of the problem. Based on a comment I wrote, it seems that in
some cases copy_user_page was being used for something that was going to
be executed. I can't remember the exact scenario, since copy_user_page
is only called in copy-on-write situations.

The problem is that since we have split I and D caches, the cache would
need to be flushed anyway so that the instructions could be seen for
execution.  So it didn't make any sense to set up the temporary
translation and then flush it anyway; better to just do it through the
kernel translation and flush.  I believe this isn't a problem on sparc64
because of the write-through cache.

> The PA-RISC mmap/write bug is something entirely different,
> flush_dcache_page() just isn't doing what it is defined to
> do :-)

Ok.  But looking at the sparc64 implementation of flush_dcache_page I
don't see any code to traverse user vma's.  Is there some other
architecture specific trick that is being used to flush any user mappings
that are mapped to the same physical address as the kernel address?

John Marvin
jsm@fc.hp.com