From: Ralf Baechle <[EMAIL PROTECTED]> Date: Sat, 19 Aug 2006 13:25:20 +0100
> So here are two alterantive fixes for the API: > > 1) Move copy_user_highpage into the arch code. This will allow the arch code > to create any sort of crazy mapping it wants. The old copy_user_page as > kernel API is only called from copy_user_highpage and would therefore be > obsoleted. > > 2) Introduce a new kmap_atomic variant to create a congruent mapping. I think you will find that copy_user_highpage() and clear_user_highpage() are performance critical enough that you will want to implement it totally in hand-crafted assembler which disables preemption, loads up the TLB entries by hand, does the copy, and flushes out the temp mappings. This is essentially what the code in arch/sparc64/lib/copy_page.S and clear_page.S is all about. So I'd lean towards #1. That's the reason copy_user_page() gets a virtual address in the first place. It's just HIGHMEM configs that make it difficult and try to do the mapping for you. You're definitely right that if you try to use a cache flush to implement clear_user_page() and copy_user_page(), you will risk data corruption. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
