[valgrind] [Bug 344524] store conditional of guest applications always fail - observed on Octeon3(MIPS)

[Maran Pakkirisamy]

https://bugs.kde.org/show_bug.cgi?id=344524

--- Comment #20 from Maran Pakkirisamy  
---
Sorry, just now I noticed this update.
And then found in bug #369459 that the issues are taken care and fixed. Thanks.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 344524] store conditional of guest applications always fail - observed on Octeon3(MIPS)

[Julian Seward]

https://bugs.kde.org/show_bug.cgi?id=344524

--- Comment #19 from Julian Seward  ---
Hmm, even that is too relaxed, because it doesn't reject mismatched
load vs store sizes.  Here's a variant that does check sizes, and 
uses size == 0 to mean "no transaction pending".

LoadLinked(addr)

  gs.LLsize = load_size // 1, 2, 4 or 8
  gs.LLaddr = addr
  gs.LLdata = zeroExtend(*addr)

StoreCond(addr, data)

  tmp_LLsize = gs.LLsize
  gs.LLsize = 0 // "no transaction"
  if tmp_LLsize != store_size-> fail
  if addr != gs.LLaddr   -> fail
  if zeroExtend(*addr) != gs.LLdata  -> fail
  cas_ok = CAS(store_size, addr, gs.LLdata -> data)
  if !cas_ok -> fail
  succeed

When thread scheduled

  gs.LLsize = 0 // "no transaction"

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 344524] store conditional of guest applications always fail - observed on Octeon3(MIPS)

[Julian Seward]

https://bugs.kde.org/show_bug.cgi?id=344524

--- Comment #18 from Julian Seward  ---
Actually, I'd prefer to have it so that any attempt to do StoreCond
will cause all following attempts to fail, up until a new LoadLinked
is done.  How does that sound?

  LoadLinked(addr)

gs.LLvalid = 1
gs.LLaddr  = addr
gs.LLdata  = *addr

  StoreCond(addr, data)

tmp_LLvalid = gs.LLvalid
gs.LLvalid = 0
if tmp_LLvalid != 1   -> fail
if addr != gs.LLaddr  -> fail
if *addr != gs.LLdata -> fail
cas_ok = CAS(addr, gs.LLdata -> data)
if !cas_ok-> fail
succeed

  When thread scheduled

gs.LLvalid = 0

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 344524] store conditional of guest applications always fail - observed on Octeon3(MIPS)

[Julian Seward]

https://bugs.kde.org/show_bug.cgi?id=344524

--- Comment #17 from Julian Seward  ---
Also, your implementation uses guest_state.LLaddr == 0 to mean "there
is no transaction in progress".  So guest_state.LLaddr == 0 has a special
meaning that is different from all other values.

I'd prefer to remove that special meaning and instead use a third
boolean field.  Also, it seems safer to invalidate any in-progress
transaction when the thread is scheduled, not de scheduled.  So my
pseudocode summary so far is

  LoadLinked(addr)

gs.LLvalid = 1
gs.LLaddr  = addr
gs.LLdata  = *addr

  StoreCond(addr, data)

if gs.LLvalid != 1)   -> fail
if addr != gs.LLaddr  -> fail
if *addr != gs.LLdata -> fail
cas_ok = CAS(addr, gs.LLdata -> data)
if !cas_ok-> fail
gs.LLvalid = 0
succeed

  When thread scheduled

gs.LLvalid = 0

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 344524] store conditional of guest applications always fail - observed on Octeon3(MIPS)

[Julian Seward]

https://bugs.kde.org/show_bug.cgi?id=344524

--- Comment #16 from Julian Seward  ---
(In reply to Maran Pakkirisamy from comment #8)

Maran,

I was studying this bug and your fix, so as to see how to apply it to ARM.
I have a question:

> With the update, only step 3 is changed.
> [..]
> c) (a and b failed). Execute SC under CAS. That is, store will be performed
> if LLdata (saved when LL was executed) is same as SCdata (the current value
> at mem). And this step is performed atomically using CAS. This is the
> significant part of the change from the initial proposal. 

Your implementation ignores whether the CAS was successful or not.

Should it instead cause the SC to fail (set rt to zero) if the CAS fails?

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 344524] store conditional of guest applications always fail - observed on Octeon3(MIPS)

[Tom Hughes]

https://bugs.kde.org/show_bug.cgi?id=344524

Tom Hughes  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||t...@compton.nu
 Status|UNCONFIRMED |RESOLVED

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 344524] store conditional of guest applications always fail - observed on Octeon3(MIPS)

[Petar Jovanovic]

https://bugs.kde.org/show_bug.cgi?id=344524

--- Comment #15 from Petar Jovanovic  ---
We should close this issue now.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 344524] store conditional of guest applications always fail - observed on Octeon3(MIPS)

[Petar Jovanovic]

https://bugs.kde.org/show_bug.cgi?id=344524

Petar Jovanovic  changed:

   What|Removed |Added

 CC||mips3...@gmail.com

--- Comment #14 from Petar Jovanovic  ---
The changes have been committed as:

Valgrind r16269
VEX r3316

Thanks Maran for the patches and sorry for the very long delay on this issue.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 344524] store conditional of guest applications always fail - observed on Octeon3(MIPS)

[Maran Pakkirisamy]

https://bugs.kde.org/show_bug.cgi?id=344524

--- Comment #13 from Maran Pakkirisamy  
---
Our internal team continuously regtests V with the patch (solution in comments
9 and 10) and also ships the package. No issues related to this bug has been
reported so far.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 344524] store conditional of guest applications always fail - observed on Octeon3(MIPS)

[Julian Seward via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=344524

--- Comment #12 from Julian Seward  ---
Maran, the same problem has been reported for ARM64/OCTEON3 at
https://bugs.kde.org/show_bug.cgi?id=369459.   So let me ask: how well
does your proposed solution in comments 9 and 10 work?  Did you deploy
it?

-- 
You are receiving this mail because:
You are watching all bug changes.