why does /dev/md call cpu_dcache_flush()?

[Ian Lepore]

On Wed, 2013-10-16 at 20:18 +0000, Poul-Henning Kamp wrote:
> In message <1381953459.1168.48.camel at revolution.hippie.lan>, Ian Lepore writes:
> >The only caller of cpu_dcache_flush() in the entire system appears to be
> >the md device.  Does anybody know why it makes the call?
> 
> r192323 | marcel | 2009-05-18 18:37:18 +0000 (Mon, 18 May 2009) | 20 lines
> 
> Add cpu_flush_dcache() for use after non-DMA based I/O so that a
> possible future I-cache coherency operation can succeed. On ARM
> for example the L1 cache can be (is) virtually mapped, which
> means that any I/O that uses temporary mappings will not see the
> I-cache made coherent. On ia64 a similar behaviour has been
> observed. By flushing the D-cache, execution of binaries backed
> by md(4) and/or NFS work reliably.
> For Book-E (powerpc), execution over NFS exhibits SIGILL once in
> a while as well, though cpu_flush_dcache() hasn't been implemented
> yet.
> 
> Doing an explicit D-cache flush as part of the non-DMA based I/O
> read operation eliminates the need to do it as part of the
> I-cache coherency operation itself and as such avoids pessimizing
> the DMA-based I/O read operations for which D-cache are already
> flushed/invalidated. It also allows future optimizations whereby
> the bcopy() followed by the D-cache flush can be integrated in a
> single operation, which could be implemented using on-chips DMA
> engines, by-passing the D-cache altogether.
> 

Hrm.  Now I feel dumb for not finding that obviously-available info for
myself.  But I guess I'll get over that and move on to what I would have
posted if I had found it...

The first part of the comment about temporary mappings on ARM is
outdated, although it would have been true at the time that was written.
Nowadays if multiple mappings are made to the same memory on VIVT ARM
chips, all mappings are changed to non-cacheable to avoid those
problems.

I think the rest of it is just wrong.  Data read in from any source may
be in the caches when the read is done, whether the source was memory or
anything else.  Even if DMA was involved at some point, if bounce
buffers were used that involves copying memory->memory after the DMA
completes and it's quite likely some of that data is still in the
caches.  

-- Ian