Messages in this thread | | | From | "Michael S. Zick" <> | Subject | Re: LOCK prefix on uni processor has its use (was Re: [BUG FIX] Make x86_32 uni-processor Atomic ops, Atomic) | Date | Wed, 27 May 2009 12:25:03 -0500 |
| |
On Wed May 27 2009, Thomas Gleixner wrote: > On Wed, 27 May 2009, Harald Welte wrote: > > Here are some statements from the CPU logic guys at VIA/Centaur: > > > > * A read-modify-write sequence cannot be interupted. > > * All X86 instructions except rep-strings are atomic wrt interrupts. > > * The lock prefix has uses on a UP processor: It keeps DMA devices from > > interfering with a read-modify-write sequence > ... > > > Now if I understand the issues correctly, it would mean that there is some > > driver code that modifies a certain chunk of memory, while DMA of some > > peripheral is also accessing that memory. I suppose it would not have to be > > the same actual address, but probably being within the same cache line is > > already sufficient. > > > > Now the question is: Is this a valid operation of a driver? Should the driver > > do such things, or is such a driver broken? When would that occur? I'm trying > > to come up with a case, but typically you e.g. allocate some DMA buffer and > > then don't touch it until the hardware has processed it. > > Right, that would be more than stupid, but even then it would not > explain any breakage of the kernel. Such a driver would not be > functional anyway if it relies on some read/write modify operations in > an active DMA buffer. That would also explode on any other system as > you have no control whether the access to that memory happens before > or after the DMA operation. >
IFF your DMA buffer is cache-line aligned and doesn't have an immediately adjacent spin-lock (or some such thing) sharing the cache-line.
Mike > Can you please ask them to clarify that DMA issue further ? > > Thanks, > > tglx > >
| |