[lkml]   [2003]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] cache flush bug in mm/filemap.c (all kernels >= 2.5.30(at least))
Hugh Dickins <> wrote:
> 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.

That sounds distinctly possible.

> 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.

Vague statement of principle: The device driver layer takes care of these
issues for DMA transfers, and hence should also take care of them for PIO.
Is this sensible and/or possible?

> 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?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:35    [W:0.062 / U:1.640 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site