]> git.baikalelectronics.ru Git - kernel.git/commit
sunvnet - add missing rmb() for sunvnet driver
authorDavid L Stevens <david.stevens@oracle.com>
Mon, 8 Sep 2014 20:23:01 +0000 (16:23 -0400)
committerDavid S. Miller <davem@davemloft.net>
Mon, 8 Sep 2014 21:08:14 +0000 (14:08 -0700)
commit2453e0ba5a929929b54f668987ca8899ddf30849
tree90abae1eed91cbee171d5ffa0ccd118e43526e25
parente019478b30b86749fd8708b443ac484f3bcd70a6
sunvnet - add missing rmb() for sunvnet driver

The sunvnet driver does not have an rmb() in the ring consumer corresponding
to the wmb() in the producer. According to Documentation/memory-barriers.txt:

"When dealing with CPU-CPU interactions, certain types of memory barrier should
always be paired.  A lack of appropriate pairing is almost certainly an error."

In cases where an rmb() is not a no-op and a consumer is removing data from
the ring while a producer is adding new entries, a load reorder would allow

CPU1 CPU2
---- ----
LOAD desc.size [e.g]
STORE desc.size
<wmb>
set desc.hdr.state = VIO_DESC_READY
LOAD desc.hdr.state
[because VIO_DESC_READY, use
 old desc.size, already loaded
 out of order]

[CPU2 has reordered apparently unrelated LOADs]

To ensure other desc fields are not loaded before checking VIO_DESC_READY, we
need an rmb() between the check and desc data accesses.

I've also moved the viodbg() call to after the rmb() so that it, too, has
current descriptor data even with reordering, which has the side effect that
it won't print anything for descriptors that are not VIO_DESC_READY as before.
That's a) probably a good thing, since the fields are not necessarily set and,
b) better than adding another rmb() just for viodbg().

This would not be possible if strict-ordering is enforced, but then the
memory barriers should be no-ops in that case.

Signed-off-by: David L Stevens <david.stevens@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net/ethernet/sun/sunvnet.c