[Top] [All Lists]

Re: Memory corruption

To: "Gleb O. Raiko" <>
Subject: Re: Memory corruption
From: "William J. Earl" <>
Date: Thu, 8 Jul 1999 10:56:41 -0700 (PDT)
Cc: "William J. Earl" <>, Warner Losh <>, Harald Koerfgen <>, Ralf Baechle <>,,,, Ulf Carlsson <>
In-reply-to: <>
References: <> <> <> <>
Gleb O. Raiko writes:
 > "William J. Earl" wrote:
 > >       The R3000 has a write-through cache, so there cannot be dirty cache
 > > lines, although you do have to flush the write buffers to be completely
 > > correct (in the case of a DMA device writing to memory VERY quickly after
 > > the register write which starts it up, on some hardware).
 > You must flush d-cache after dma. While some cache controllers are able
 > to watch the bus and flush the data that are invalidated due to DMA
 > transfers, I think, most r3k boxes doesn't have such beasts. Flushing
 > d-cache wasn't implemented at the same time as the cache stuff because
 > we hadn't boxes with DMA devices.

     Most R3000 (and many R4000/R4600/R5000) boxes do not have
cache-coherent I/O, and Linux/MIPS does do cache flushing.  If
everything is well-organized, one can flush the d-cache only before an
I/O.  On an R3000, it does not much matter which approach you take,
since the caches are write-through (aside from the need to flush the
write-buffer before initiating a DMA).  For later processors, you must
flush the d-cache BEFORE a DMA, since victim writebacks of dirty lines
after a DMA into memory has updated memory will lead to I/O data
corruption, and failure to flush dirty lines before a DMA from memory
will lead to stale data being written to disk.  If it is possible for
the CPU to access the buffer during the DMA, then you must invalidate
the cache for the buffer after a DMA into memory as well, but a
well-constructed system should never do that.  

    If you have a buffer which is not cache-line-aligned (which is
possible with the general case of raw or direct I/O, although not in
unmodified Linux at the moment), then, for DMA into memory, you must
use temporary buffers for any portion of the buffer which occupies
just part of a cache line, and copy the data from the temporary buffer
to the real buffer after the DMA completes, to account for the
possibility of a separate thread modifying data outside the buffer in
the shared cache line, leading to a victim writeback (or a
writethrough on the R3000).  This could apply even to the R3000, depending
on how the compiler generates code for a partial-word update, although
it is unlikely.

<Prev in Thread] Current Thread [Next in Thread>