- 03 Jul, 2006 40 commits
-
-
Ingo Molnar authored
3c59x.c's vortex_timer() function knows that vp->lock can only be used by an irq context that it disabled - and can hence take the vp->lock without disabling hardirqs. Teach lockdep about this. Has no effect on non-lockdep kernels. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Ingo Molnar authored
8390.c knows that ei_local->page_lock can only be used by an irq context that it disabled - and can hence take the ->page_lock without disabling hardirqs. Teach lockdep about this. Has no effect on non-lockdep kernels. Signed-off-by:
-
Arjan van de Ven authored
The ops structure has complex locking rules, where not all ops are equal, some are subordinate on others for some complex sound cards. This requires for lockdep checking that each individual reg_mutex is considered in separation for its locking rules. Has no effect on non-lockdep kernels. Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Takashi Iwai <tiwai@suse.de> Cc: Jaroslav Kysela <perex@suse.cz> 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:
-
Arjan van de Ven authored
In usbfs's fs_remove_file() function, the aim is to remove a file or directory from usbfs. This is done by first taking the i_mutex of the parent directory of this file/dir via mutex_lock(&parent->d_inode->i_mutex); and then to call either usbfs_rmdir() for a directory or usbfs_unlink() for a file. Both these functions then take the i_mutex for the to-be-removed object themselves: mutex_lock(&inode->i_mutex); This is a classical parent->child locking order relationship that the VFS uses all over the place; the VFS locking rule is "you need to take the parent first". This patch annotates the usbfs code to make this explicit and thus informs the lockdep code that those two locks indeed have this relationship. The rules for unlink that we already use in the VFS for unlink are to use I_MUTEX_PARENT for the parent directory, and a normal mutex for the file itself; this patch follows that convention. Has no effect on non-lockdep kernels. Signed-off-by:
-
Arjan van de Ven authored
The quota code plays interesting games with the lock ordering; to quote Jan: | i_mutex of inode containing quota file is acquired after all other | quota locks. i_mutex of all other inodes is acquired before quota | locks. Quota code makes sure (by resetting inode operations and | setting special flag on inode) that noone tries to enter quota code | while holding i_mutex on a quota file... The good news is that all of this special case i_mutex grabbing happens in the (per filesystem) low level quota write function. For this special case we need a new I_MUTEX_* nesting level, since this just entirely outside any of the regular VFS locking rules for i_mutex. I trust Jan on his blue eyes that this is not ever going to deadlock; and based on that the patch below is what it takes to inform lockdep of these very interesting new locking rules. The new locking rule for the I_MUTEX_QUOTA nesting level is that this is the deepest possible level of nesting for i_mutex, and that this only should be used in quota write (and possibly read) function of filesystems. This makes the lock ordering of the I_MUTEX_* levels: I_MUTEX_PARENT -> I_MUTEX_CHILD -> I_MUTEX_NORMAL -> I_MUTEX_QUOTA Has no effect on non-lockdep kernels. Signed-off-by:
-
Ingo Molnar authored
NTFS uses lots of type-opaque objects which acquire their true identity runtime - so the lock validator needs to be helped in a couple of places to figure out object types. Many thanks to Anton Altaparmakov for giving lots of explanations about NTFS locking rules. Has no effect on non-lockdep kernels. Signed-off-by:
Anton Altaparmakov <aia21@cantab.net> Signed-off-by:
-
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:
-
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:
-
