Re: Memory synchronization vs. interrupt handlers

[Alan Stern]

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