Re: Memory synchronization vs. interrupt handlers

[Paul E. McKenney]

On Wed, Aug 28, 2013 at 01:28:08PM -0700, H. Peter Anvin wrote:
> On 08/28/2013 12:16 PM, Alan Stern wrote:
> > Russell, Peter, and Ingo:
> > 
> > Can you folks enlighten us regarding this issue for some common 
> > architectures?
> 
> On x86, IRET is a serializing instruction; it guarantees hard
> serialization of absolutely everything.

So a second interrupt from this same device could not appear to happen
before the IRET, no matter what device and/or I/O bus?  Or is IRET
defined to synchronize all the way out to the whatever device is
generating the next interrupt?

> I would expect architectures that have weak memory ordering to put
> appropriate barriers in the IRQ entry/exit code.

Adding a few on CC.  Also restating the question as I understand it:

	Suppose that a given device generates an interrupt on CPU 0,
	but that before CPU 0's interrupt handler completes, this device
	wants to generate a second interrupt on CPU 1.  This can happen
	as soon as CPU 0's handler does an EOI or equivalent.

	Can CPU 1's interrupt handler assume that all the in-memory effects
	of CPU 0's interrupt handler will be visible, even if neither
	interrupt handler uses locking or memory barriers?

							Thanx, Paul

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