1. 25 Nov, 2016 1 commit
  2. 03 Oct, 2014 1 commit
    • Peter Zijlstra's avatar
      locking/lockdep: Revert qrwlock recusive stuff · 8acd91e8
      Peter Zijlstra authored
      Commit f0bab73c ("locking/lockdep: Restrict the use of recursive
      read_lock() with qrwlock") changed lockdep to try and conform to the
      qrwlock semantics which differ from the traditional rwlock semantics.
      In particular qrwlock is fair outside of interrupt context, but in
      interrupt context readers will ignore all fairness.
      The problem modeling this is that read and write side have different
      lock state (interrupts) semantics but we only have a single
      representation of these. Therefore lockdep will get confused, thinking
      the lock can cause interrupt lock inversions.
      So revert it for now; the old rwlock semantics were already imperfectly
      modeled and the qrwlock extra won't fit either.
      If we want to properly fix this, I think we need to resurrect the work
      by Gautham did a few years ago that split the read and write state of
      FWIW the locking selftest that would've failed (and was reported by
      Borislav earlier) is something like:
        RL(X1);	/* IRQ-ON */
        RL(X1);	/* IN-IRQ */
      At which point it would report that because A is an IRQ-unsafe lock we
      can suffer the following inversion:
      	CPU0		CPU1
      And this is 'wrong' because X1 can recurse (assuming the above lock are
      in fact read-lock) but lockdep doesn't know about this.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Waiman Long <Waiman.Long@hp.com>
      Cc: ego@linux.vnet.ibm.com
      Cc: bp@alien8.de
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/20140930132600.GA7444@worktop.programming.kicks-ass.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
  3. 13 Aug, 2014 1 commit
  4. 25 Sep, 2013 1 commit
  5. 12 Jul, 2013 1 commit
  6. 26 Jun, 2013 4 commits
  7. 19 Feb, 2013 1 commit
  8. 07 Mar, 2012 1 commit
  9. 26 May, 2011 1 commit
    • Frederic Weisbecker's avatar
      rcu: Fix unpaired rcu_irq_enter() from locking selftests · ba9f207c
      Frederic Weisbecker authored
      HARDIRQ_ENTER() maps to irq_enter() which calls rcu_irq_enter().
      But HARDIRQ_EXIT() maps to __irq_exit() which doesn't call
      So for every locking selftest that simulates hardirq disabled,
      we create an imbalance in the rcu extended quiescent state
      internal state.
      As a result, after the first missing rcu_irq_exit(), subsequent
      irqs won't exit dyntick-idle mode after leaving the interrupt
      handler.  This means that RCU won't see the affected CPU as being
      in an extended quiescent state, resulting in long grace-period
      delays (as in grace periods extending for hours).
      To fix this, just use __irq_enter() to simulate the hardirq
      context. This is sufficient for the locking selftests as we
      don't need to exit any extended quiescent state or perform
      any check that irqs normally do when they wake up from idle.
      As a side effect, this patch makes it possible to restore
      "rcu: Decrease memory-barrier usage based on semi-formal proof",
      which eventually helped finding this bug.
      Reported-and-tested-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Stable <stable@kernel.org>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
  10. 13 Mar, 2009 1 commit
  11. 07 Dec, 2006 1 commit
  12. 03 Jul, 2006 3 commits
    • Ingo Molnar's avatar
      [PATCH] lockdep: allow read_lock() recursion of same class · 6c9076ec
      Ingo Molnar authored
      From: Ingo Molnar <mingo@elte.hu>
      lockdep so far only allowed read-recursion for the same lock instance.
      This is enough in the overwhelming majority of cases, but a hostap case
      triggered and reported by Miles Lane relies on same-class
      different-instance recursion.  So we relax the restriction on read-lock
      (This change does not allow rwsem read-recursion, which is still
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Ingo Molnar's avatar
      [PATCH] lockdep: core · fbb9ce95
      Ingo Molnar authored
      Do 'make oldconfig' and accept all the defaults for new config options -
      reboot into the kernel and if everything goes well it should boot up fine and
      you should have /proc/lockdep and /proc/lockdep_stats files.
      Typically if the lock validator finds some problem it will print out
      voluminous debug output that begins with "BUG: ..." and which syslog output
      can be used by kernel developers to figure out the precise locking scenario.
      What does the lock validator do?  It "observes" and maps all locking rules as
      they occur dynamically (as triggered by the kernel's natural use of spinlocks,
      rwlocks, mutexes and rwsems).  Whenever the lock validator subsystem detects a
      new locking scenario, it validates this new rule against the existing set of
      rules.  If this new rule is consistent with the existing set of rules then the
      new rule is added transparently and the kernel continues as normal.  If the
      new rule could create a deadlock scenario then this condition is printed out.
      When determining validity of locking, all possible "deadlock scenarios" are
      considered: assuming arbitrary number of CPUs, arbitrary irq context and task
      context constellations, running arbitrary combinations of all the existing
      locking scenarios.  In a typical system this means millions of separate
      scenarios.  This is why we call it a "locking correctness" validator - for all
      rules that are observed the lock validator proves it with mathematical
      certainty that a deadlock could not occur (assuming that the lock validator
      implementation itself is correct and its internal data structures are not
      corrupted by some other kernel subsystem).  [see more details and conditionals
      of this statement in include/linux/lockdep.h and
      Furthermore, this "all possible scenarios" property of the validator also
      enables the finding of complex, highly unlikely multi-CPU multi-context races
      via single single-context rules, increasing the likelyhood of finding bugs
      drastically.  In practical terms: the lock validator already found a bug in
      the upstream kernel that could only occur on systems with 3 or more CPUs, and
      which needed 3 very unlikely code sequences to occur at once on the 3 CPUs.
      That bug was found and reported on a single-CPU system (!).  So in essence a
      race will be found "piecemail-wise", triggering all the necessary components
      for the race, without having to reproduce the race scenario itself!  In its
      short existence the lock validator found and reported many bugs before they
      actually caused a real deadlock.
      To further increase the efficiency of the validator, the mapping is not per
      "lock instance", but per "lock-class".  For example, all struct inode objects
      in the kernel have inode->inotify_mutex.  If there are 10,000 inodes cached,
      then there are 10,000 lock objects.  But ->inotify_mutex is a single "lock
      type", and all locking activities that occur against ->inotify_mutex are
      "unified" into this single lock-class.  The advantage of the lock-class
      approach is that all historical ->inotify_mutex uses are mapped into a single
      (and as narrow as possible) set of locking rules - regardless of how many
      different tasks or inode structures it took to build this set of rules.  The
      set of rules persist during the lifetime of the kernel.
      To see the rough magnitude of checking that the lock validator does, here's a
      portion of /proc/lockdep_stats, fresh after bootup:
       lock-classes:                            694 [max: 2048]
       direct dependencies:                  1598 [max: 8192]
       indirect dependencies:               17896
       all direct dependencies:             16206
       dependency chains:                    1910 [max: 8192]
       in-hardirq chains:                      17
       in-softirq chains:                     105
       in-process chains:                    1065
       stack-trace entries:                 38761 [max: 131072]
       combined max dependencies:         2033928
       hardirq-safe locks:                     24
       hardirq-unsafe locks:                  176
       softirq-safe locks:                     53
       softirq-unsafe locks:                  137
       irq-safe locks:                         59
       irq-unsafe locks:                      176
      The lock validator has observed 1598 actual single-thread locking patterns,
      and has validated all possible 2033928 distinct locking scenarios.
      More details about the design of the lock validator can be found in
      Documentation/lockdep-design.txt, which can also found at:
      [bunk@stusta.de: cleanups]
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Ingo Molnar's avatar
      [PATCH] lockdep: locking API self tests · cae2ed9a
      Ingo Molnar authored
      Introduce DEBUG_LOCKING_API_SELFTESTS, which uses the generic lock debugging
      code's silent-failure feature to run a matrix of testcases.  There are 210
      testcases currently:
        | Locking API testsuite:
                                       | spin |wlock |rlock |mutex | wsem | rsem |
                           A-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                       A-B-B-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                   A-B-B-C-C-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                   A-B-C-A-B-C deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
               A-B-B-C-C-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
               A-B-C-D-B-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
               A-B-C-D-B-C-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                          double unlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                       bad unlock order:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                    recursive read-lock:             |  ok  |             |  ok  |
                      non-nested unlock:  ok  |  ok  |  ok  |  ok  |
           hard-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
           soft-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
           hard-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
           soft-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
             sirq-safe-A => hirqs-on/12:  ok  |  ok  |  ok  |
             sirq-safe-A => hirqs-on/21:  ok  |  ok  |  ok  |
               hard-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
               soft-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
               hard-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
               soft-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #2/321:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #2/321:  ok  |  ok  |  ok  |
            hard-irq lock-inversion/123:  ok  |  ok  |  ok  |
            soft-irq lock-inversion/123:  ok  |  ok  |  ok  |
            hard-irq lock-inversion/132:  ok  |  ok  |  ok  |
            soft-irq lock-inversion/132:  ok  |  ok  |  ok  |
            hard-irq lock-inversion/213:  ok  |  ok  |  ok  |
            soft-irq lock-inversion/213:  ok  |  ok  |  ok  |
            hard-irq lock-inversion/231:  ok  |  ok  |  ok  |
            soft-irq lock-inversion/231:  ok  |  ok  |  ok  |
            hard-irq lock-inversion/312:  ok  |  ok  |  ok  |
            soft-irq lock-inversion/312:  ok  |  ok  |  ok  |
            hard-irq lock-inversion/321:  ok  |  ok  |  ok  |
            soft-irq lock-inversion/321:  ok  |  ok  |  ok  |
            hard-irq read-recursion/123:  ok  |
            soft-irq read-recursion/123:  ok  |
            hard-irq read-recursion/132:  ok  |
            soft-irq read-recursion/132:  ok  |
            hard-irq read-recursion/213:  ok  |
            soft-irq read-recursion/213:  ok  |
            hard-irq read-recursion/231:  ok  |
            soft-irq read-recursion/231:  ok  |
            hard-irq read-recursion/312:  ok  |
            soft-irq read-recursion/312:  ok  |
            hard-irq read-recursion/321:  ok  |
            soft-irq read-recursion/321:  ok  |
        Good, all 210 testcases passed! |
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>