From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: David Howells <dhowells@redhat.com>,
Ming Lei <ming.lei@canonical.com>,
USB list <linux-usb@vger.kernel.org>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: Memory synchronization vs. interrupt handlers
Date: Tue, 27 Aug 2013 18:19:23 -0700 [thread overview]
Message-ID: <20130828011923.GS3871@linux.vnet.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1308261129200.1445-100000@iolanthe.rowland.org>
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.
> Does the answer change if the IRQ line is shared? I wouldn't expect
> it to be.
>
> Now, if the handler were bound to multiple IRQ (or MSI) lines, then
> there'd be no reason to expect this to work. However, even in this
> case, it seems that as long as we restrict our attention to handler
> invocations in response to interrupt requests from one particular IRQ
> line, the answer should be Yes. (For example, if device X on IRQ I and
> device Y on IRQ J both used the same handler, a write to A in response
> to an interrupt from device X should be visible the next time X sends
> an interrupt.)
>
> Do you know the answers?
I believe that we need to ask the architecture maintainers. And maybe
also someone who knows about the devices in question.
Thanx, Paul
next prev parent reply other threads:[~2013-08-28 2:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CACVXFVMi8VU=m_XkdToAWtMDj-AJ2H+Jz6J4yy0=YWAweV1UMA@mail.gmail.com>
2013-08-26 15:49 ` Memory synchronization vs. interrupt handlers Alan Stern
2013-08-28 1:19 ` Paul E. McKenney [this message]
2013-08-28 19:16 ` Alan Stern
2013-08-28 20:28 ` H. Peter Anvin
2013-08-29 14:19 ` Alan Stern
2013-08-29 23:51 ` Paul E. McKenney
2013-08-30 0:14 ` Benjamin Herrenschmidt
2013-08-30 3:26 ` H. Peter Anvin
2013-09-02 11:43 ` Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130828011923.GS3871@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=ming.lei@canonical.com \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox