[valgrind] [Bug 344524] store conditional of guest applications always fail - observed on Octeon3(MIPS)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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.