Russell, Peter, and Ingo: Can you folks enlighten us regarding this issue for some common architectures? On Tue, 27 Aug 2013, Paul E. McKenney wrote: > On Mon, Aug 26, 2013 at 11:49:15AM -0400, Alan Stern wrote: > > David and Paul: > > > > Here's a question that doesn't seem to be answered in > > Documentation/memory-barriers.txt. Are memory accesses within an > > interrupt handler synchronized with respect to interrupts? > > > > In more detail, suppose we have an interrupt handler that uses a memory > > variable A. The device attached to the IRQ line sends two interrupt > > requests, and we get: > > > > CPU 0 CPU 1 > > ----- ----- > > Receive IRQ > > Call the interrupt handler > > Write A > > Finish IRQ processing > > > > Receive IRQ > > Call the interrupt handler > > Read A > > Finish IRQ processing > > > > Is CPU 0's write to A guaranteed to be visible on CPU 1? Given that > > interrupts on an IRQ line are serialized, and that IRQ processing must > > involve some amount of memory barriers, I would expect the answer to be > > Yes. > > I have no idea. I would hope that it did, but a lot depends on how or > whether the end-of-interrupt processing is handled by the I/O hardware. Isn't this the sort of thing the kernel should guarantee? The low-level code that fields interrupts ought to do the equivalent of an "acquire" barrier at the start and a "release" barrier at the end, so that operations by the higher-level handlers don't "leak out". For example, if the low-level code would lock and unlock a spinlock at the start and end of the interrupt, that would be more than sufficient (provided it always used the same spinlock for the same IRQ line). Of course, drivers needing this behavior can always use their own spinlocks. Still, it seems like this ought to fall under the purview of the core kernel. > I believe that we need to ask the architecture maintainers. And maybe > also someone who knows about the devices in question. The devices aren't relevant here because the variable A resides in main memory, not on the device. What matter is, as you say, the architectural code. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
