On 2016-10-05 11:30, bdegr...@codeaurora.org wrote:
On 2016-10-05 11:10, Peter Zijlstra wrote:
On Wed, Oct 05, 2016 at 10:55:57AM -0400, bdegr...@codeaurora.org wrote:
On 2016-10-04 15:12, Mark Rutland wrote:
>Hi Brent,
>Could you *please* clarify if you are trying to solve:
>(a) a correctness issue (e.g. data corruption) seen in practice.
>(b) a correctness issue (e.g. data corruption) found by inspection.
>(c) A performance issue, seen in practice.
>(d) A performance issue, found by inspection.
>Any one of these is fine; we just need to know in order to be able to
>help effectively, and so far it hasn't been clear.

Brent, you forgot to state which: 'a-d' is the case here.

I found the problem.

Back in September of 2013, arm64 atomics were broken due to missing barriers
in certain situations, but the problem at that time was undiscovered.

Will Deacon's commit d2212b4dce596fee83e5c523400bf084f4cc816c went in at
time and changed the correct cmpxchg64 in lockref.c to cmpxchg64_relaxed.

d2212b4 appeared to be OK at that time because the additional barrier
requirements of this specific code sequence were not yet discovered, and
this change was consistent with the arm64 atomic code of that time.

Around February of 2014, some discovery led Will to correct the problem with the atomic code via commit 8e86f0b409a44193f1587e87b69c5dcf8f65be67, which has an excellent explanation of potential ordering problems with the same
code sequence used by lockref.c.

With this updated understanding, the earlier commit
(d2212b4dce596fee83e5c523400bf084f4cc816c) should be reverted.

Because acquire/release semantics are insufficient for the full ordering, the single barrier after the store exclusive is the best approach, similar
to Will's atomic barrier fix.

This again does not in fact describe the problem.

What is the problem with lockref, and how (refer the earlier a-d
multiple choice answer) was this found.

Now, I have been looking, and we have some idea what you _might_ be
alluding to, but please explain which accesses get reordered how and
cause problems.

Sorry for the confusion, this was a "b" item (correctness fix based on code inspection. I had sent an answer to this yesterday, but didn't realize that
it was in a separate, private email thread.

I'll work out the before/after problem scenarios and send them along once I've hashed them out (it may take a while for me to paint a clear picture). In the meantime, however, consider that even without the spinlock code in the picture, lockref needs to treat the cmpxchg as a full system-level atomic, because multiple agents could access the value in a variety of timings. Since atomics similar to this are barriered on arm64 since 8e86f0b, the access to
lockref should be similar.


I am still working through some additional analyses for mixed accesses, but I thought I'd send along some sample commit text for the fix as it currently stands. Please feel free to comment if you see something that needs clarification.



All arm64 lockref accesses that occur without taking the spinlock must behave like true atomics, ensuring successive operations are all done sequentially. Currently
the lockref accesses, when decompiled, look like the following sequence:

                    <Lockref "unlocked" Access [A]>

                    // Lockref "unlocked" (B)
                1:  ldxr   x0, [B]         // Exclusive load
                     <change lock_count B>
                    stxr   w1, x0, [B]
                    cbnz   w1, 1b

                     <Lockref "unlocked" Access [C]>

Even though access to the lock_count is protected by exclusives, this is not enough to guarantee order: The lock_count must change atomically, in order, so the only
permitted ordering would be:
                              A -> B -> C

Unfortunately, this is not the case by the letter of the architecture and, in fact, the accesses to A and C are not protected by any sort of barrier, and hence are
permitted to reorder freely, resulting in orderings such as

                           Bl -> A -> C -> Bs

In this specific scenario, since "change lock_count" could be an increment, a decrement or even a set to a specific value, there could be trouble. With more agents accessing the lockref without taking the lock, even scenarios where the cmpxchg passes falsely can be encountered, as there is no guarantee that the the "old" value will not match exactly a newer value due to out-of-order access by a combination of agents that
increment and decrement the lock_count by the same amount.

Since multiple agents are accessing this without locking the spinlock, this access must have the same protections in place as atomics do in the arch's atomic.h. Fortunately, the fix is not complicated: merely removing the errant _relaxed option on the cmpxchg64 is enough to introduce exactly the same code sequence justified
in commit 8e86f0b409a44193f1587e87b69c5dcf8f65be67 to fix arm64 atomics.

                   1:  ldxr   x0, [B]
                       <change lock_count>
                       stlxr   w1, x0, [B]
                       cbnz   w1, 1b
                       dmb    ish

Reply via email to