Messages in this thread | | | Date | Sat, 30 Dec 2006 21:23:38 -0800 (PST) | Subject | Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again | From | David Miller <> |
| |
From: Russell King <rmk+lkml@arm.linux.org.uk> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |