inconsistent lock state (2.6.34, XFS inode shrinker)
in [Kernel]
|
Prev: [PATCH 3/3] scripts: Change section of generated debian packages to kernel
Next: smack: opt_dentry is never null in in smack_d_instantiate()
From: Dave Chinner on 1 Jun 2010 20:00 On Tue, Jun 01, 2010 at 12:13:22PM +0200, Pedro M. L�pez wrote: > ================================= > [ INFO: inconsistent lock state ] > 2.6.34 #1 > --------------------------------- > inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage. > kswapd0/227 [HC0[0]:SC0[0]:HE1:SE1] takes: > (&(&ip->i_iolock)->mr_lock#2){++++?+}, at: [<ffffffff8112c11f>] > xfs_ilock+0x27/0x79 {RECLAIM_FS-ON-W} state was registered at: > [<ffffffff810510f5>] mark_held_locks+0x52/0x70 > [<ffffffff81051198>] lockdep_trace_alloc+0x85/0x9f > [<ffffffff81073db2>] __alloc_pages_nodemask+0x7b/0x5b5 > [<ffffffff8106f1e2>] grab_cache_page_write_begin+0x65/0xaa > [<ffffffff810bfaaa>] block_write_begin+0x38/0xcd > [<ffffffff81146f1f>] xfs_vm_write_begin+0x25/0x27 > [<ffffffff8106e140>] generic_file_buffered_write+0x114/0x271 > [<ffffffff8114aa31>] xfs_file_aio_write+0x4e1/0x70c > [<ffffffff8109d187>] do_sync_write+0xc6/0x103 > [<ffffffff8109db5f>] vfs_write+0xad/0x172 > [<ffffffff8109dcdd>] sys_write+0x45/0x6c > [<ffffffff81001f2b>] system_call_fastpath+0x16/0x1b > irq event stamp: 62175 > hardirqs last enabled at (62175): [<ffffffff8126fb03>] > _raw_spin_unlock_irqrestore+0x3a/0x60 hardirqs last disabled at > (62174): [<ffffffff8126f3a9>] _raw_spin_lock_irqsave+0x17/0x58 softirqs > last enabled at (61572): [<ffffffff8103398d>] __do_softirq+0x127/0x13e > softirqs last disabled at (61543): [<ffffffff81002dcc>] > call_softirq+0x1c/0x28 > > other info that might help us debug this: > 2 locks held by kswapd0/227: > #0: (shrinker_rwsem){++++..}, at: [<ffffffff810797f0>] > shrink_slab+0x38/0x144 #1: (&xfs_mount_list_lock){++++.-}, at: > [<ffffffff811503fc>] xfs_reclaim_inode_shrink+0x35/0x128 > > stack backtrace: > Pid: 227, comm: kswapd0 Not tainted 2.6.34 #1 > Call Trace: > [<ffffffff81050b72>] print_usage_bug+0x1a4/0x1b5 > [<ffffffff8100c995>] ? save_stack_trace+0x2a/0x47 > [<ffffffff810516bc>] ? check_usage_forwards+0x0/0xcf > [<ffffffff81050e6d>] mark_lock+0x2ea/0x520 > [<ffffffff81052b8a>] __lock_acquire+0x6c1/0x1607 > [<ffffffff8116820b>] ? radix_tree_delete+0xd1/0x1d0 > [<ffffffff81053b27>] lock_acquire+0x57/0x6d > [<ffffffff8112c11f>] ? xfs_ilock+0x27/0x79 > [<ffffffff81046939>] down_write_nested+0x2a/0x4d > [<ffffffff8112c11f>] ? xfs_ilock+0x27/0x79 > [<ffffffff8112c11f>] xfs_ilock+0x27/0x79 > [<ffffffff8112c2eb>] xfs_ireclaim+0x93/0xb1 > [<ffffffff8114f949>] xfs_reclaim_inode+0x1de/0x20a > [<ffffffff81150299>] xfs_inode_ag_walk+0x8b/0xe6 > [<ffffffff8114f76b>] ? xfs_reclaim_inode+0x0/0x20a > [<ffffffff81150374>] xfs_inode_ag_iterator+0x80/0xd3 > [<ffffffff8114f76b>] ? xfs_reclaim_inode+0x0/0x20a > [<ffffffff81150428>] xfs_reclaim_inode_shrink+0x61/0x128 > [<ffffffff8107988b>] shrink_slab+0xd3/0x144 > [<ffffffff81079c61>] balance_pgdat+0x365/0x59b > [<ffffffff81077908>] ? isolate_pages_global+0x0/0x212 > [<ffffffff8107a089>] kswapd+0x1f2/0x20f > [<ffffffff81042e89>] ? autoremove_wake_function+0x0/0x34 > [<ffffffff8126fb24>] ? _raw_spin_unlock_irqrestore+0x5b/0x60 > [<ffffffff81079e97>] ? kswapd+0x0/0x20f > [<ffffffff81042ac7>] kthread+0x7a/0x82 > [<ffffffff81002cd4>] kernel_thread_helper+0x4/0x10 > [<ffffffff8126ff40>] ? restore_args+0x0/0x30 > [<ffffffff81042a4d>] ? kthread+0x0/0x82 > [<ffffffff81002cd0>] ? kernel_thread_helper+0x0/0x10 It's a false positive introduced in 2.6.34 by the inode shrinker. That's one of several different false positive traces in 2.6.34, but I can't do anything about them because the shrinkers require global scope. The patches to customise the shrinker contexts (which avoids all of these warnings) will fix this.... You may as well not run lockdep on anything with an XFS filesystem, as these false positives will occur as soon as memory reclaim triggers and turn lockdep off. Cheers, Dave. -- Dave Chinner david(a)fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |