- 04 Jul, 2006 3 commits
-
-
Heiko Carstens authored
================================= [ INFO: inconsistent lock state ] --------------------------------- inconsistent {in-hardirq-W} -> {hardirq-on-W} usage. swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes: (&adapter->fsf_req_list_lock){++..}, at: [<0000000000274486>] zfcp_qdio_reqid_check+0x46/0x178 {in-hardirq-W} state was registered at: [<000000000005fb0c>] __lock_acquire+0xad8/0xed0 [<00000000000604ae>] lock_acquire+0x9a/0xc8 [<000000000035a326>] _spin_lock+0x4e/0x68 [<0000000000274486>] zfcp_qdio_reqid_check+0x46/0x178 [<000000000027469e>] zfcp_qdio_response_handler+0xe6/0x430 [<0000000000219dd4>] tiqdio_thinint_handler+0xd20/0x213c [<000000000020229a>] do_adapter_IO+0xb2/0xc0 [<0000000000206f32>] do_IRQ+0x136/0x16c [<0000000000020462>] io_no_vtime+0x16/0x1c [<0000000000019432>] cpu_idle+0x222/0x250 irq event stamp: 129220 hardirqs last enabled at (129220): [<00000000000411e6>] tasklet_hi_action+0x5a/0x19c hardirqs last disabled at (129219): [<00000000000411c0>] tasklet_hi_action+0x34/0x19c softirqs last enabled at (129212): [<0000000000040b62>] __do_softirq+0x13a/0x180 softirqs last disabled at (129217): [<000000000001fd58>] do_softirq+0xec/0xf0 other info that might help us debug this: no locks held by swapper/0. stack backtrace: 00000000012bb670 0000000000000002 0000000000000000 00000000012bb780 00000000012bb6e8 0000000000399122 0000000000399122 0000000000016b0a 0000000000000000 0000000000000000 0000000000000000 00000000004660e8 0000000000000000 000000000000000d 00000000012bb6e0 00000000012bb758 0000000000368b90 0000000000016b0a 00000000012bb6e0 00000000012bb730 Call Trace: ([<0000000000016a26>] show_trace+0x76/0xdc) [<0000000000016b2c>] show_stack+0xa0/0xd0 [<0000000000016b8a>] dump_stack+0x2e/0x3c [<000000000005e3da>] print_usage_bug+0x27e/0x290 [<000000000005ea9c>] mark_lock+0x6b0/0x6c0 [<000000000005f33e>] __lock_acquire+0x30a/0xed0 [<00000000000604ae>] lock_acquire+0x9a/0xc8 [<000000000035a326>] _spin_lock+0x4e/0x68 [<0000000000274486>] zfcp_qdio_reqid_check+0x46/0x178 [<000000000027469e>] zfcp_qdio_response_handler+0xe6/0x430 [<0000000000217bd2>] tiqdio_tl+0xd02/0x2120 [<000000000004123a>] tasklet_hi_action+0xae/0x19c [<0000000000040ae4>] __do_softirq+0xbc/0x180 [<000000000001fd58>] do_softirq+0xec/0xf0 [<0000000000040c38>] irq_exit+0x90/0xa8 [<0000000000206f40>] do_IRQ+0x144/0x16c [<0000000000020462>] io_no_vtime+0x16/0x1c [<0000000000019432>] cpu_idle+0x222/0x250 ([<0000000000019416>] cpu_idle+0x206/0x250) [<000000000001405a>] rest_init+0x5a/0x68 [<0000000000536998>] start_kernel+0x39c/0x3dc [<0000000000013046>] _stext+0x46/0x1000 Fix incorrect usage of fsf_req_list_lock. It's used in tasklet context (irqs on) as well as in irq context. Therefore use the spin_lock_irqsave variant to avoid deadlocks. Acked-by:Andreas Herrmann <aherrman@de.ibm.com> Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Heiko Carstens authored
================================= [ INFO: inconsistent lock state ] --------------------------------- inconsistent {hardirq-on-W} -> {in-hardirq-W} usage. swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes: (&adapter->erp_lock){+-..}, at: [<000000000026c7f8>] zfcp_erp_async_handler+0x3c/0x70 {hardirq-on-W} state was registered at: [<000000000005f33e>] __lock_acquire+0x30a/0xed0 [<00000000000604ae>] lock_acquire+0x9a/0xc8 [<000000000035a7ae>] _write_lock+0x4e/0x68 [<000000000026d822>] zfcp_erp_adapter_strategy_generic+0x286/0xd94 [<000000000026fd72>] zfcp_erp_strategy_do_action+0x91e/0x1a94 [<0000000000271a3a>] zfcp_erp_thread+0x21a/0x1568 [<0000000000019096>] kernel_thread_starter+0x6/0xc [<0000000000019090>] kernel_thread_starter+0x0/0xc irq event stamp: 12078 hardirqs last enabled at (12077): [<0000000000019416>] cpu_idle+0x206/0x250 hardirqs last disabled at (12078): [<0000000000020458>] io_no_vtime+0xc/0x1c softirqs last enabled at (12072): [<0000000000040b62>] __do_softirq+0x13a/0x180 softirqs last disabled at (12059): [<000000000001fd58>] do_softirq+0xec/0xf0 other info that might help us debug this: no locks held by swapper/0. stack backtrace: 00000000012bb648 0000000000000002 0000000000000000 00000000012bb758 00000000012bb6c0 0000000000399122 0000000000399122 0000000000016b0a 0000000000000000 0000000000000001 0000000000000000 00000000004660e8 0000000000000000 000000000000000d 00000000012bb6b8 00000000012bb730 0000000000368b90 0000000000016b0a 00000000012bb6b8 00000000012bb708 Call Trace: ([<0000000000016a26>] show_trace+0x76/0xdc) [<0000000000016b2c>] show_stack+0xa0/0xd0 [<0000000000016b8a>] dump_stack+0x2e/0x3c [<000000000005e3da>] print_usage_bug+0x27e/0x290 [<000000000005e934>] mark_lock+0x548/0x6c0 [<000000000005fb0c>] __lock_acquire+0xad8/0xed0 [<00000000000604ae>] lock_acquire+0x9a/0xc8 [<000000000035a662>] _write_lock_irqsave+0x62/0x80 [<000000000026c7f8>] zfcp_erp_async_handler+0x3c/0x70 [<0000000000279178>] zfcp_fsf_req_dispatch+0xd8/0x1fa8 [<000000000027e538>] zfcp_fsf_req_complete+0x104/0xe4c [<0000000000274534>] zfcp_qdio_reqid_check+0xf4/0x178 [<000000000027469e>] zfcp_qdio_response_handler+0xe6/0x430 [<0000000000219dd4>] tiqdio_thinint_handler+0xd20/0x213c [<000000000020229a>] do_adapter_IO+0xb2/0xc0 [<0000000000206f32>] do_IRQ+0x136/0x16c [<0000000000020462>] io_no_vtime+0x16/0x1c [<0000000000019432>] cpu_idle+0x222/0x250 ([<0000000000019416>] cpu_idle+0x206/0x250) [<000000000001405a>] rest_init+0x5a/0x68 [<0000000000536998>] start_kernel+0x39c/0x3dc [<0000000000013046>] _stext+0x46/0x1000 Fix incorrect usage of erp_lock. Using the write_lock() variant is wrong, since this might lead to deadlocks. Acked-by: -
OGAWA Hirofumi authored
With recent change, if CONFIG_HOTPLUG_CPU is disabled, register_cpu_notifier() is not exported. And it breaked moduler msr/cpuid (msr.c was already fixed). We need to use register_hotcpu_notifier() now in module, instead of register_cpu_notifier(). Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
-
- 03 Jul, 2006 37 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpcLinus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc: powerpc: add defconfig for Freescale MPC8349E-mITX board powerpc: Add base support for the Freescale MPC8349E-mITX eval board Documentation: correct values in MPC8548E SEC example node [POWERPC] Actually copy over i8259.c to arch/ppc/syslib this time [POWERPC] Add new interrupt mapping core and change platforms to use it [POWERPC] Copy i8259 code back to arch/ppc [POWERPC] New device-tree interrupt parsing code [POWERPC] Use the genirq framework [PATCH] genirq: Allow fasteoi handler to retrigger disabled interrupts [POWERPC] Update the SWIM3 (powermac) floppy driver [POWERPC] Fix error handling in detecting legacy serial ports [POWERPC] Fix booting on Momentum "Apache" board (a Maple derivative) [POWERPC] Fix various offb and BootX-related issues [POWERPC] Add a default config for 32-bit CHRP machines [POWERPC] fix implicit declaration on cell. [POWERPC] change get_property to return void *
-
Ingo Molnar authored
convert: - runqueue_t to 'struct rq' - prio_array_t to 'struct prio_array' - migration_req_t to 'struct migration_req' I was the one who added these but they are both against the kernel coding style and also were used inconsistently at places. So just get rid of them at once, now that we are flushing the scheduler patch-queue anyway. Conversion was mostly scripted, the result was reviewed and all secondary whitespace and style impact (if any) was fixed up by hand. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Ingo Molnar authored
cleanup: remove task_t and convert all the uses to struct task_struct. I introduced it for the scheduler anno and it was a mistake. Conversion was mostly scripted, the result was reviewed and all secondary whitespace and style impact (if any) was fixed up by hand. Signed-off-by:
-
Ingo Molnar authored
Clean up some of the impact of recent (and not so recent) scheduler changes: - turning macros into nice inline functions - sanitizing and unifying variable definitions - whitespace, style consistency, 80-lines, comment correctness, spelling and curly braces police Due to the macro hell and variable placement simplifications there's even 26 bytes of .text saved: text data bss dec hex filename 25510 4153 192 29855 749f sched.o.before 25484 4153 192 29829 7485 sched.o.after [akpm@osdl.org: build fix] Signed-off-by:
-
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 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:
-
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:
-
