On Wed, Feb 03, 2010 at 12:25:07PM -0600, James Bottomley wrote: > On Tue, 2010-02-02 at 13:44 -0800, akpm@xxxxxxxxxxxxxxxxxxxx wrote: > > From: anfei zhou <anfei.zhou@xxxxxxxxx> > > > > The cache alias problem will happen if the changes of user shared mapping > > is not flushed before copying, then user and kernel mapping may be mapped > > into two different cache line, it is impossible to guarantee the coherence > > after iov_iter_copy_from_user_atomic. So the right steps should be: > > > > flush_dcache_page(page); > > This is likely unnecessary if the page has come down a standard path ... > for fuse, it is possible it didn't go through __get_user_pages(). > The problem here is iov_iter_copy_from_user_atomic will write the page, and that page has been written by (*addr = val) before, but not flushed yet. If these two writes are at the same cache line (but aliased), then we can not guarantee the result by any order. > > kmap_atomic(page); > > write to page; > > kunmap_atomic(page); > > flush_dcache_page(page); > > > > More precisely, we might create two new APIs flush_dcache_user_page and > > flush_dcache_kern_page to replace the two flush_dcache_page accordingly. > > We already have one of those: flush_kernel_dcache_page(). > Yes, but it's only called in a few places, and others usually use flush_dcache_page, why? And not every arch with aliasing problem has implement it, such as MIPS. Regards, Anfei. > James > > -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
