Re: [patch] cache flush bug in mm/filemap.c (all kernels >= 2.5.30(at least))

[Russell King <rmk@arm.linux.org.uk>]

On Fri, May 23, 2003 at 03:45:51AM -0700, Andrew Morton wrote:
> Given that there was no page at the virtual address before filemap_nopage
> was called I don't think any CPU cache writeback or invalidation need be
> performed.  Perhaps a writeback or invalidate is missing somewhere in the
> unmap paths, or there is a problem in arch/arm somewhere.

No, I think there is a flush missing somewhere in this path.

What I think is happening is that Lothar is using the PXA with the cache
in write allocate write back mode (Xscale is the first ARM-arch cpu to
have allocate on write caches.)

This means that when IDE copies the data into the buffer using insw or
whatever, it ends up in the VIVT cache rather than memory.  Since we
don't seem to be calling flush_dcache_page(), we never write this data
back to memory for user space to access it via their mapping.

If this is the case, its something I can't test, because I don't have
access to such hardware (I'm currently being kept a hardware pauper
as far as new ARM technologies go.)

> We have a no-op flush_icache_page() in do_no_page(), but I don't know what
> that thing ever did, not what it's doing in there.  (What happens if you
> replace it with a flush_cache_page(vma, address)?)

I don't think this'll help - its asking the wrong bit of cache to be
flushed.  I think we want to replace that flush_icache_page() with
a flush_dcache_page(), but shrug, I don't really know this code well
enough.

> Someone who understands these things better than I is going to have
> to work out where the bug really is, I'm afraid.

I suspect that there's very few people who really understand this area -
you need to know what the block drivers are doing, and everything in
between there and user space.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html