From: James Bottomley <[EMAIL PROTECTED]> Date: Sun, 19 Mar 2006 11:15:58 -0600
> The problem, essentially is that get_user_pages() doesn't return a > coherent view of anonymous pages to the kernel. The reason is that > get_user_pages() uses flush_dcache_page() as its engine of coherence, > and a lot of flush_dcache_page() implementations use the page_mapping() > macros to get a list of user mappings of the page. The page_mapping() > macro (include/linux/mm.h) returns NULL if the PAGE_MAPPING_ANON flag is > set, this means that flush_dcache_page() has no list of user mappings, > so nothing gets flushed in user space. > > A lot of arch's don't have an incoherent view of user and kernel > mappings, so I think this problem perhaps affects only parisc and arm. flush_dcache_page() implementations intentionally don't operate on anonymous pages because the kernel should only ever access anonymous pages via: 1) copy_user_highpage()/clear_user_highpage(), where you can handle the D-cache issues there. 2) device DMA, where the L2 cache eviction done by the device DMA will pull out the D-cache entries, or if the block I/O is via PIO it will do cache flushing in there, as per some asm-*/ide.h implementations of __ide_ins*()/__ide_outs*() 3) ptrace poking You've found a case that doesn't go through any special interfaces, and thus is not handled properly at the current time. - 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
