1. 20 Feb, 2015 1 commit
  2. 11 Feb, 2015 1 commit
  3. 02 Feb, 2015 1 commit
  4. 27 Jan, 2015 2 commits
  5. 17 Jan, 2015 1 commit
  6. 13 Jan, 2015 1 commit
  7. 19 Dec, 2014 1 commit
  8. 11 Dec, 2014 1 commit
  9. 08 Dec, 2014 8 commits
  10. 05 Dec, 2014 1 commit
  11. 12 Nov, 2014 1 commit
  12. 10 Nov, 2014 3 commits
  13. 06 Nov, 2014 2 commits
  14. 31 Oct, 2014 1 commit
  15. 30 Oct, 2014 2 commits
  16. 25 Oct, 2014 3 commits
  17. 20 Oct, 2014 1 commit
  18. 01 Oct, 2014 1 commit
  19. 30 Sep, 2014 5 commits
  20. 12 Sep, 2014 1 commit
  21. 09 Sep, 2014 1 commit
  22. 08 Sep, 2014 1 commit
    • David L Stevens's avatar
      sunvnet - add missing rmb() for sunvnet driver · 78dcff7b
      David L Stevens authored
      
      
      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: default avatarDavid L Stevens <david.stevens@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      78dcff7b