Thread (116 messages) 116 messages, 11 authors, 2017-07-10

Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions

From: Will Deacon <hidden>
Date: 2017-07-03 17:13:44
Also in: linux-arch, lkml, netfilter-devel

On Mon, Jul 03, 2017 at 09:40:22AM -0700, Linus Torvalds wrote:
On Mon, Jul 3, 2017 at 9:18 AM, Paul E. McKenney
[off-list ref] wrote:
quoted
Agreed, and my next step is to look at spin_lock() followed by
spin_is_locked(), not necessarily the same lock.
Hmm. Most (all?) "spin_is_locked()" really should be about the same
thread that took the lock (ie it's about asserts and lock debugging).

The optimistic ABBA avoidance pattern for spinlocks *should* be

    spin_lock(inner)
    ...
    if (!try_lock(outer)) {
           spin_unlock(inner);
           .. do them in the right order ..

so I don't think spin_is_locked() should have any memory barriers.

In fact, the core function for spin_is_locked() is arguably
arch_spin_value_unlocked() which doesn't even do the access itself.
Yeah, but there's some spaced-out stuff going on in kgdb_cpu_enter where
it looks to me like raw_spin_is_locked is used for synchronization. My
eyes are hurting looking at it, though.

Will
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help