- 03 Jul, 2006 40 commits
-
-
Arjan van de Ven authored
Add i_mutex ordering annotations to the sunrpc rpc_pipe code. This code has 3 levels of i_mutex hierarchy in some cases: parent dir, client dir and file inside client dir; the i_mutex ordering is I_MUTEX_PARENT -> I_MUTEX_CHILD -> I_MUTEX_NORMAL This patch applies this ordering annotation to the various functions. This is in line with the VFS expected ordering where it is always OK to lock a child after locking a parent; the sunrpc code is very diligent in doing this correctly. Has no effect on non-lockdep kernels. Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Trond Myklebust <trond.myklebust@fys.uio.no> Cc: Neil Brown <neilb@suse.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Ingo Molnar authored
Teach special (recursive) locking code to the lock validator. Has no effect on non-lockdep kernels. Signed-off-by:
-
Ingo Molnar authored
ieee1394 reuses the skb infrastructure of the networking code, and uses two skb-head queues: ->pending_packet_queue and hpsbpkt_queue. The latter is used in the usual fashion: processed from a kernel thread. The other one, ->pending_packet_queue is also processed from hardirq context (f.e. in hpsb_bus_reset()), which is not what the networking code usually does (which completes from softirq or process context). This locking assymetry can be totally correct if done carefully, but it can also be dangerous if networking helper functions are reused, which could assume traditional networking use. It would probably be more robust to push this completion into a workqueue - but technically the code can be 100% correct, and lockdep has to be taught about it. The solution is to split the ->pending_packet_queue skb-head->lock class from the networking lock-class by using a private lock-validator key. Has no effect on non-lockdep kernels. Signed-off-by:
-
Ingo Molnar authored
Teach special (recursive) locking code to the lock validator. Has no effect on non-lockdep kernels. Signed-off-by:
-
Ingo Molnar authored
Teach special (recursive) locking code to the lock validator. Also splits af_unix's sk_receive_queue.lock class from the other networking skb-queue locks. Has no effect on non-lockdep kernels. Signed-off-by:
-
Ingo Molnar authored
Teach special (multi-initialized, per-address-family) locking code to the lock validator. Has no effect on non-lockdep kernels. Signed-off-by:
-
Ingo Molnar authored
Teach special (recursive) locking code to the lock validator. Has no effect on non-lockdep kernels. Signed-off-by:
-
Ingo Molnar authored
Teach per-CPU runqueue locks and recursive locking code to the lock validator. Has no effect on non-lockdep kernels. Signed-off-by:
-
Ingo Molnar authored
Split the per-CPU timer base locks up into separate lock classes, because they are used recursively. Has no effect on non-lockdep kernels. Signed-off-by:
-
Ingo Molnar authored
Teach special (multi-initialized) locking code to the lock validator. Has no effect on non-lockdep kernels. Signed-off-by:
-
Arjan van de Ven authored
The PS/2 code has a natural device order and there is a one level recursion in this device order in terms of the cmd_mutex; annotate this explicit recursion as ok. Has no effect on non-lockdep kernels. Signed-off-by:
-
Ingo Molnar authored
Teach special (recursive) locking code to the lock validator. Has no effect on non-lockdep kernels. Signed-off-by:
-
Ingo Molnar authored
Create one lock class for all waitqueue locks in the kernel. Has no effect on non-lockdep kernels. Signed-off-by:
-
Ingo Molnar authored
Teach special (recursive) locking code to the lock validator. Has no effect on non-lockdep kernels. Signed-off-by:
-
Ingo Molnar authored
Teach special (recursive) locking code to the lock validator. Introduces double_lock_hb() to unify double- hash-bucket-lock taking. Signed-off-by:
-
Ingo Molnar authored
Teach special (recursive) locking code to the lock validator. Has no effect on non-lockdep kernels. Signed-off-by:
-
Ingo Molnar authored
Teach special (recursive) locking code to the lock validator. Has no effect on non-lockdep kernels. Signed-off-by:
-
Ingo Molnar authored
Teach special (dual-initialized) locking code to the lock validator. Has no effect on non-lockdep kernels. Signed-off-by:
-
Ingo Molnar authored
Teach special (rwsem-in-irq) locking code to the lock validator. Has no effect on non-lockdep kernels. Signed-off-by:
-
Ingo Molnar authored
Enable LOCKDEP_SUPPORT on s390. Signed-off-by:
-
Ingo Molnar authored
Enable LOCKDEP_SUPPORT on x86_64. Signed-off-by:
-
Ingo Molnar authored
Enable LOCKDEP_SUPPORT on i386. Signed-off-by:
-
Heiko Carstens authored
Machine checks on s390 are always enabled (except in the machine check handler itself). Therefore use lockdep_off()/on() in the machine check handler to avoid deadlocks in the lock validator. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Acked-by:
-
Ingo Molnar authored
On lockdep we have a quite big spinlock_t, so keep the size down. Signed-off-by:
-
Ingo Molnar authored
Make printk()-ing from within the lock validation code safer by using the lockdep-recursion counter. Signed-off-by:
-
Ingo Molnar authored
Disable SMP alternatives fixups (the patching in of NOPs on 1-CPU systems) if the lock validator is enabled: there is a binutils section handling bug that causes corrupted instructions when UP instructions are patched in. Signed-off-by:
-
Ingo Molnar authored
x86_64 uses spinlocks very early - earlier than start_kernel(). So call lockdep_init() from the arch setup code. Signed-off-by:
-
Ingo Molnar authored
Print all lock-classes on SysRq-D. Signed-off-by:
-
Ingo Molnar authored
Offer the following lock validation options: CONFIG_PROVE_LOCKING Signed-off-by:
-
Ingo Molnar authored
Use the lock validator framework to prove mutex locking correctness. Signed-off-by:
-
Ingo Molnar authored
Use the lock validator framework to prove spinlock and rwlock locking correctness. Signed-off-by:
-
Ingo Molnar authored
Use the lock validator framework to prove rwsem locking correctness. Signed-off-by:
-
Ingo Molnar authored
Lock validator /proc/lockdep and /proc/lockdep_stats support. (FIXME: should go into debugfs) Signed-off-by:
-
Ingo Molnar authored
Lock validator design documentation. Signed-off-by:
-
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 recursion. (This change does not allow rwsem read-recursion, which is still forbidden.) Signed-off-by:
-
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 Documentation/lockdep-design.txt] 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: http://redhat.com/~mingo/lockdep-patches/lockdep-design.txt [bunk@stusta.de: cleanups] Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
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: -
Heiko Carstens authored
irqtrace support for s390. Signed-off-by:
-
Ingo Molnar authored
Clean up the x86-64 irqflags.h file: - macro => inline function transformation - simplifications - style fixes Signed-off-by:
-
Ingo Molnar authored
Add irqflags-tracing support to x86_64. [akpm@osdl.org: build fix] Signed-off-by:
-
