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

From	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Newsgroups	linux.kernel
Subject	Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions
Date	2017-07-04 02:50 +0200
Message-ID	<tZkcp-FC-5@gated-at.bofh.it> (permalink)
References	(5 earlier) <tZceT-3TE-43@gated-at.bofh.it> <tZcHT-43W-11@gated-at.bofh.it> <tZdaW-4tv-9@gated-at.bofh.it> <tZiaC-7Qj-7@gated-at.bofh.it> <tZitZ-7Ys-9@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Mon, Jul 03, 2017 at 03:49:42PM -0700, Linus Torvalds wrote:
> On Mon, Jul 3, 2017 at 3:30 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
> >
> > 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?  ;-)
> 
> Deadlock due to interrupts again?

Unless I am missing something subtle, the kgdb_cpu_enter() function in
question has a local_irq_save() over the "interesting" portion of its
workings, so interrupt-handler self-deadlock should not happen.

> Didn't your spin_unlock_wait() patches teach you anything? Checking
> state is fundamentally different from taking the lock. Even a trylock.

That was an embarrassing bug, no two ways about it.  :-/

> I guess you could try with the irqsave versions. But no, we're not doing that.

Again, no need in this case.

But I agree with Will's assessment of this function...

The raw_spin_is_locked() looks to be asking if -any- CPU holds the
dbg_slave_lock, and the answer could of course change immediately
on return from raw_spin_is_locked().  Perhaps the theory is that
if other CPU holds the lock, this CPU is supposed to be subjected to
kgdb_roundup_cpus().  Except that the CPU that held dbg_slave_lock might
be just about to release that lock.  Odd.

Seems like there should be a get_online_cpus() somewhere, but maybe
that constraint is to be manually enforced.

							Thanx, Paul

Thread

Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic  definitions "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-03 18:20 +0200
  Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-03 18:50 +0200
    Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic  definitions Will Deacon <will.deacon@arm.com> - 2017-07-03 19:20 +0200
      Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic  definitions "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-04 00:40 +0200
        Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-04 01:00 +0200
          Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic  definitions "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-04 02:50 +0200
            Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic  definitions "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-04 03:00 +0200
    Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic  definitions "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-03 23:20 +0200

csiph-web