- 03 Jul, 2006 40 commits
-
-
Paul Mackerras authored
At the moment, powerpc and s390 have their own versions of do_softirq which include local_bh_disable() and __local_bh_enable() calls. They end up calling __do_softirq (in kernel/softirq.c) which also does local_bh_disable/enable. Apparently the two levels of disable/enable trigger a warning from some validation code that Ingo is working on, and he would like to see the outer level removed. But to do that, we have to move the account_system_vtime calls that are currently in the arch do_softirq() implementations for powerpc and s390 into the generic __do_softirq() (this is a no-op for other archs because account_system_vtime is defined to be an empty inline function on all other archs). This patch does that. Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Ingo Molnar authored
nv_do_nic_poll() is called from timer softirqs, which has interrupts enabled, but np->lock might also be taken by some other interrupt context. The driver does disable_irq() to get around this problem, so annotate the disable_irq()/enable_irq() calls for lockdep. Has no effect on non-lockdep kernels. Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Cc: Ayaz Abdulla <aabdulla@nvidia.com> Cc: Manfred Spraul <manfred@colorfullife.com> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
Andrew Morton authored
Someone went nuts in there. Cc: Ayaz Abdulla <aabdulla@nvidia.com> Cc: Manfred Spraul <manfred@colorfullife.com> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
Arjan van de Ven authored
On Fri, 2006-06-30 at 15:45 -0700, Miles Lane wrote: > Okay, I rebuilt my kernel with your combo patch applied. > Then, I inserted my US Robotics USR2210 PCMCIA wifi card, > ran "pccardutil eject", popped out the card and then inserted > a Compaq iPaq wifi card. This triggered the following. > > [ INFO: possible circular locking dependency detected ] > ------------------------------------------------------- > syslogd/1886 is trying to acquire lock: > (&dev->queue_lock){-+..}, at: [<c11a50b5>] dev_queue_xmit+0x120/0x24b > > but task is already holding lock: > (&dev->_xmit_lock){-+..}, at: [<c11a5118>] dev_queue_xmit+0x183/0x24b > > which lock already depends on the new lock. ok this appears to be hostap playing games... it has 2 network devices for one piece of hardware and one calls the other via the networking layer; there is thankfully a natural ordering between the two, so just making the slave one a separate type ought to make this work. Signed-off-by: -
Ingo Molnar authored
Teach sk_lock semantics to the lock validator. In the softirq path the slock has mutex_trylock()+mutex_unlock() semantics, in the process context sock_lock() case it has mutex_lock()/mutex_unlock() semantics. Thus we treat sock_owned_by_user() flagged areas as an exclusion area too, not just those areas covered by a held sk_lock.slock. Effect on non-lockdep kernels: minimal, sk_lock_sock_init() has been turned into an inline function. Signed-off-by:
-
Ingo Molnar authored
lockdep needs to have the waitqueue lock initialized for on-stack waitqueues implicitly initialized by DECLARE_COMPLETION(). Annotate mmc_wait_for_req()'s on-stack completion accordingly. Has no effect on non-lockdep kernels. Signed-off-by:
-
Arjan van de Ven authored
vlan network devices have devices nesting below it, and are a special "super class" of normal network devices; split their locks off into a separate class since they always nest. [deweerdt@free.fr: fix possible null-pointer deref] Signed-off-by:
Frederik Deweerdt <frederik.deweerdt@gmail.com> Signed-off-by:
-
Ingo Molnar authored
Teach special (recursive) locking code to the lock validator. Effects on non-lockdep kernels: - the introduction of the following function variants: extern struct block_device *open_partition_by_devnum(dev_t, unsigned); extern int blkdev_put_partition(struct block_device *); static int blkdev_get_whole(struct block_device *bdev, mode_t mode, unsigned flags); which on non-lockdep are the same as open_by_devnum(), blkdev_put() and blkdev_get(). - a subclass parameter to do_open(). [unused on non-lockdep] - a subclass parameter to __blkdev_put(), which is a new internal function for the main blkdev_put*() functions. [parameter unused on non-lockdep kernels, except for two sanity check WARN_ON()s] these functions carry no semantical difference - they only express object dependencies towards the lockdep subsystem. Signed-off-by:
-
Ingo Molnar authored
Teach special (recursive) locking code to the lock validator. Has no effect on non-lockdep kernels. Fix initialize-locks-via-memcpy assumptions. Effects on non-lockdep kernels: the subclass nesting parameter is passed into cache_free_alien() and __cache_free(), and turns one internal kmem_cache_free() call into an open-coded __cache_free() call. Signed-off-by:
-
Arjan van de Ven authored
The s_umount rwsem needs to be classified as per-superblock since it's perfectly legit to keep multiple of those recursively in the VFS locking rules. Has no effect on non-lockdep kernels. Signed-off-by:
-
Ingo Molnar authored
Teach special (per-filesystem) locking code to the lock validator. Minimal effect on non-lockdep kernels: one extra parameter to alloc_super(). Signed-off-by:
-
Heiko Carstens authored
Annotate the qeth driver which uses a private skb-queue-head that is safely used in hardirq context too. Has no effect on non-lockdep kernels. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Acked-by:
-
Ingo Molnar authored
lockdep needs to have the waitqueue lock initialized for on-stack waitqueues implicitly initialized by DECLARE_COMPLETION(). Annotate on-stack completions accordingly. Has no effect on non-lockdep kernels. Signed-off-by:
-
Ingo Molnar authored
Make use of local_irq_enable_in_hardirq() API to annotate places that enable hardirqs in hardirq context. Has no effect on non-lockdep kernels. Signed-off-by:
-
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 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:
-
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:
-
