Messages in this thread | | | Date | Fri, 23 May 2003 18:31:45 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: [patch] cache flush bug in mm/filemap.c (all kernels >= 2.5.30(at least)) |
| |
On Fri, 23 May 2003, Russell King wrote: > > 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.
I believe (DaveM will speak with authority) that hitherto it has been assumed that I/O (well, Input) brings data actually into memory: we use flush_dcache_page if kernel memsets or memcpys data, not if it's read in.
If this mode+architecture departs from that, then we would need another macro, which translates to flush_dcache_page (sufficient?) for that, and is a nop for everything else.
And where would it be placed? I think not where the flush_page_to_ram used to be in filemap_nopage, but after the ->readpage. Or... would this tie in with Martin's s390 request for a SetPageUptodate hook?
Hugh
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |