On Mon, Jul 03, 2017 at 06:13:38PM +0100, Will Deacon wrote:
> 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
> > <paulmck@xxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > 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.
That certainly is one interesting function, isn't it? I wonder what
happens if you replace the raw_spin_is_locked() calls with an
unlock under a trylock check? ;-)
Thanx, Paul
