copy_from_user_page/copy_to_user_page fix

copy_from_user_page/copy_to_user_page fix

[Atsushi Nemoto]

Yet another dcache aliasing problem.

Since access_process_vm() in kernel 2.6 does not call
flush_cache_page(), it seems copy_to_user_page()/copy_from_user_page()
should flush data cache to resolve aliasing.

Without this fix, gdb will not work correctly.  Could you apply?

diff -u linux-mips/include/asm-mips/cacheflush.h linux/include/asm-mips/cacheflush.h
--- linux-mips/include/asm-mips/cacheflush.h	2004-08-14 19:55:59.000000000 +0900
+++ linux/include/asm-mips/cacheflush.h	2005-02-09 17:55:39.402702039 +0900
@@ -56,11 +56,17 @@
 
 #define copy_to_user_page(vma, page, vaddr, dst, src, len)		\
 do {									\
+	if (cpu_has_dc_aliases)						\
+		flush_cache_page(vma, vaddr);				\
 	memcpy(dst, (void *) src, len);					\
 	flush_icache_page(vma, page);					\
 } while (0)
 #define copy_from_user_page(vma, page, vaddr, dst, src, len)		\
-	memcpy(dst, src, len)
+do {									\
+	if (cpu_has_dc_aliases)						\
+		flush_cache_page(vma, vaddr);				\
+	memcpy(dst, src, len);						\
+} while (0)
 
 extern void (*flush_cache_sigtramp)(unsigned long addr);
 extern void (*flush_icache_all)(void);

---
Atsushi Nemoto

Re: copy_from_user_page/copy_to_user_page fix

[Ralf Baechle]

On Wed, Feb 09, 2005 at 06:49:47PM +0900, Atsushi Nemoto wrote:

> Yet another dcache aliasing problem.
> 
> Since access_process_vm() in kernel 2.6 does not call
> flush_cache_page(), it seems copy_to_user_page()/copy_from_user_page()
> should flush data cache to resolve aliasing.
> 
> Without this fix, gdb will not work correctly.  Could you apply?

I'm going to apply this because it's a correct fix; the temporary mapping
strategy as we've discussed for the dup_mmap problem would be preferable.

  Ralf

Re: copy_from_user_page/copy_to_user_page fix

[Atsushi Nemoto]

>>>>> On Wed, 9 Feb 2005 13:51:05 +0100, Ralf Baechle <ralf@linux-mips.org> said:

ralf> I'm going to apply this because it's a correct fix; the
ralf> temporary mapping strategy as we've discussed for the dup_mmap
ralf> problem would be preferable.

Thank you.  I agree that the temporary mapping will be more efficient
though I chose a simple fix.  I suppose a performance requirement for
ptrace() would be less than the dup_mmap (fork()).

---
Atsushi Nemoto

Re: copy_from_user_page/copy_to_user_page fix

[Ralf Baechle]

On Wed, Feb 09, 2005 at 10:52:56PM +0900, Atsushi Nemoto wrote:

> ralf> I'm going to apply this because it's a correct fix; the
> ralf> temporary mapping strategy as we've discussed for the dup_mmap
> ralf> problem would be preferable.
> 
> Thank you.  I agree that the temporary mapping will be more efficient
> though I chose a simple fix.  I suppose a performance requirement for
> ptrace() would be less than the dup_mmap (fork()).

People have come up with creative abuses for ptrace which actually make
it a performance critical path.  Especially UML should be mentioned in
this cathegory.  And we're talkign about a few thousand cycles differences
per ptrace invocation.

  Ralf