Hi James,
On 02/23/2014 03:05 PM, James Bottomley wrote:
On Sat, 2014-02-22 at 14:03 -0500, Peter Hurley wrote:
If it is necessary for a RELEASE-ACQUIRE pair to produce a full barrier, the
ACQUIRE can be followed by an smp_mb__after_unlock_lock() invocation. This
will produce a full barrier if either (a) the RELEASE and the ACQUIRE are
executed by the same CPU or task, or (b) the RELEASE and ACQUIRE act on the
same variable. The smp_mb__after_unlock_lock() primitive is free on many
architectures. Without smp_mb__after_unlock_lock(), the critical sections
corresponding to the RELEASE and the ACQUIRE can cross:
*A = a;
RELEASE M
ACQUIRE N
*B = b;
could occur as:
ACQUIRE N, STORE *B, STORE *A, RELEASE M
Ah, OK, that's an error in the documentation.
AFAIK, Paul will not be changing the quoted text above.
The example should read
*A = a;
RELEASE *N*
ACQUIRE *M*
*B = b;
The point being you can't have speculation that entangles critical
sections, as I've been saying, because that would speculate you into
ABBA deadlocks. Paul McKenny will submit a patch fixing the bug in
documentation.
The reason why there is no deadlock here is because the RELEASE M is
not dependent on the ACQUIRE N to complete.
If the attempt to ACQUIRE N is speculated before the RELEASE M, two
possibilities exist:
1. N is not owned, so the ACQUIRE is immediately successful, or
2. N is owned, so the attempted ACQUIRE is not immediately successful.
However, in both cases the RELEASE M will still complete, having already
been started (since it occurred before in the instruction stream).
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
