From: Matt Evans <hidden> Date: 2011-03-25 07:44:13
On weakly-ordered systems, the reading of an event's content must occur
after reading the event's validity.
Signed-off-by: Matt Evans <redacted>
---
drivers/usb/host/xhci-ring.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
From: Matt Evans <hidden> Date: 2011-03-28 04:52:57
On weakly-ordered systems, the reading of an event's content must occur
after reading the event's validity.
Signed-off-by: Matt Evans <redacted>
---
Segher, thanks for the comment; explanation added.
drivers/usb/host/xhci-ring.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
From: Sarah Sharp <hidden> Date: 2011-03-28 22:20:23
This patch looks fine, thanks!
Sarah Sharp
On Mon, Mar 28, 2011 at 03:52:57PM +1100, Matt Evans wrote:
quoted hunk
On weakly-ordered systems, the reading of an event's content must occur
after reading the event's validity.
Signed-off-by: Matt Evans <redacted>
---
Segher, thanks for the comment; explanation added.
drivers/usb/host/xhci-ring.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
On Sunday, March 27, 2011 09:52:57 pm Matt Evans wrote:
quoted hunk
On weakly-ordered systems, the reading of an event's content must occur
after reading the event's validity.
Signed-off-by: Matt Evans <redacted>
---
Segher, thanks for the comment; explanation added.
drivers/usb/host/xhci-ring.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2011-03-29 21:23:49
On Tue, 2011-03-29 at 11:56 -0700, Dmitry Torokhov wrote:
quoted
+ /*
+ * Barrier between reading the TRB_CYCLE (valid) flag above
and any
quoted
+ * speculative reads of the event's flags/data below.+ */+ rmb(); /* FIXME: Handle more event types. */ switch ((le32_to_cpu(event->event_cmd.flags) &
TRB_TYPE_BITMASK)) {
Isn't it the same memory that is being read the first time around? How
reordering could happen here?
We don't try to enforce ordering specifically with the subsequent read
of the flags that is visible in the snipped above (indeed that's the
same address and so hopefully should be in program order), but all
subsequent reads which could have been performed speculatively such as
the rest of the event and including whatever other in memory information
the chip might have updated prior to sending the event.
Cheers,
Ben.