This issue came up while investigating why fuse doesn't work on parisc.

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.

It seems to me that once get_user_pages() has executed, we should have a
guarantee that the kernel has a coherent view of all the pages so
returned, so either flush_dcache_page() should iterate over anonymous
page mappings (my preferred solution) or get_user_pages() should have
additional coherency for anonymous pages.

Although this problem first manifested with fuse, I think we would have
a similar issue doing SG_IO on memory obtained from brk, so we're lucky
it hasn't bitten us before.

James


-
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

Reply via email to