From: Russell King <[EMAIL PROTECTED]> Date: Sat, 30 Dec 2006 22:46:04 +0000
> iirc, flush_anon_page() was introduced to fix non-working fuse on parisc, > which occurs because fuse wants to use get_user_pages() to read data from > the current processes memory space. > > get_user_pages() contains a call to flush_dcache_page(), whose behaviour > is defined for shared mappings. Anonymous pages are unspecified. It > appears that flush_anon_page() was introduced to correct this oversight. Sparc64 flushes anonymous pages too when flush_dcache_page() is called on such pages. It only tries to "defer" flushes for pages which have a non-NULL page_mapping(). For NULL page_mapping() we just flush immediately. This works on sparc64, as sort of hinted by Linus, because we can flush by physical page on sparc64. I guess the lack of ability to do that is why PARISC and ARM don't do that too. For the ptrace() cases we created the copy_{to,from}_user_page() interfaces. So that when you access data inside of pages obtained via a get_user_pages() call, you are supposed to use those two interfaces so that everything works out right. Therefore, FUSE probably could have been fixed by judicious use of copy_{to,from}_user_page() calls instead of adding this new ad-hoc flush_anon_page() thing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/