[RESEND PATCH] ARM: Handle user space mapped pages in flush_kernel_dcache_page
Russell King - ARM Linux
linux at arm.linux.org.uk
Sat Jul 28 07:27:07 EDT 2012
On Sat, Jul 28, 2012 at 10:41:54AM +0200, Simon Baatz wrote:
> a while ago I sent the patch above to fix a data corruption problem
> on VIVT architectures (and probably VIPT aliasing). There has been a
> bit of discussion with Catalin, but there was no real conclusion on
> how to proceed. (See
> http://www.spinics.net/lists/arm-kernel/msg176913.html for the
> original post)
Going back to that post:
However, this assumption is not true for direct IO or SG_IO (see
e.g.  and ). This is why vgchange fails with mv_cesa as reported
by me in . (Btw., flush_kernel_dcache_page is also called from
"copy_strings" in fs/exec.c when copying env/arg strings between
processes. Thus, its use is not restricted to device drivers.)
The calls from copy_strings is not a problem - because the newly allocated
pages will have PG_arch_1 clear, and when the page is passed to set_pte(),
it will be flushed.
We _certainly_ do not want to make flush_kernel_dcache_page() do what you're
doing, because it will mean we're over-flushing *all* pages on VIVT caches.
Not only will we be flushing them for DMA, but we'll then do it again
when flush_kernel_dcache_page() is invoked, and then possibly again when
the page eventually ends up being visible to userspace.
> The case is not hit too often apparently; the ingredients are PIO
> (like) driver, use of flush_kernel_dcache_page(), and direct I/O.
Right, so we need to analyse the direct IO paths and work out whether
they're using the flush_* interfaces correctly, and even whether they're
using the correct interfaces.
Note that flush_*dcache_page() are supposed to only be concerned with
page cache pages, not anonymous pages. flush_anon_page() is all about
anonymous pages only.
More information about the linux-arm-kernel