Messages in this thread | | | Date | Thu, 29 Aug 2013 16:51:36 -0700 | From | "Paul E. McKenney" <> | Subject | Re: Memory synchronization vs. interrupt handlers |
| |
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
| |