Re: LOCK prefix on uni processor has its use (was Re: [BUG FIX] Makex86_32 uni-processor Atomic ops, Atomic)

[Thomas Gleixner]

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.

Can you please ask them to clarify that DMA issue further ?

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/