From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id o51NmpoY032997 for ; Tue, 1 Jun 2010 18:48:51 -0500 Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5D6BD1584CA7 for ; Tue, 1 Jun 2010 16:53:34 -0700 (PDT) Received: from mail.internode.on.net (bld-mail16.adl2.internode.on.net [150.101.137.101]) by cuda.sgi.com with ESMTP id KKXwtUXcXCgAWjJF for ; Tue, 01 Jun 2010 16:53:34 -0700 (PDT) Date: Wed, 2 Jun 2010 09:51:11 +1000 From: Dave Chinner Subject: Re: inconsistent lock state (2.6.34, XFS inode shrinker) Message-ID: <20100601235111.GH1395@dastard> References: <20100601121322.1e8f9edf@multimensaje.es> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20100601121322.1e8f9edf@multimensaje.es> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com To: Pedro =?iso-8859-1?Q?M=2E_L=F3pez?= Cc: Linux Kernel list , xfs@oss.sgi.com On Tue, Jun 01, 2010 at 12:13:22PM +0200, Pedro M. L=F3pez wrote: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > [ 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: [] > xfs_ilock+0x27/0x79 {RECLAIM_FS-ON-W} state was registered at: > [] mark_held_locks+0x52/0x70 > [] lockdep_trace_alloc+0x85/0x9f > [] __alloc_pages_nodemask+0x7b/0x5b5 > [] grab_cache_page_write_begin+0x65/0xaa > [] block_write_begin+0x38/0xcd > [] xfs_vm_write_begin+0x25/0x27 > [] generic_file_buffered_write+0x114/0x271 > [] xfs_file_aio_write+0x4e1/0x70c > [] do_sync_write+0xc6/0x103 > [] vfs_write+0xad/0x172 > [] sys_write+0x45/0x6c > [] system_call_fastpath+0x16/0x1b > irq event stamp: 62175 > hardirqs last enabled at (62175): [] > _raw_spin_unlock_irqrestore+0x3a/0x60 hardirqs last disabled at > (62174): [] _raw_spin_lock_irqsave+0x17/0x58 softirqs > last enabled at (61572): [] __do_softirq+0x127/0x13e > softirqs last disabled at (61543): [] > call_softirq+0x1c/0x28 > = > other info that might help us debug this: > 2 locks held by kswapd0/227: > #0: (shrinker_rwsem){++++..}, at: [] > shrink_slab+0x38/0x144 #1: (&xfs_mount_list_lock){++++.-}, at: > [] xfs_reclaim_inode_shrink+0x35/0x128 > = > stack backtrace: > Pid: 227, comm: kswapd0 Not tainted 2.6.34 #1 > Call Trace: > [] print_usage_bug+0x1a4/0x1b5 > [] ? save_stack_trace+0x2a/0x47 > [] ? check_usage_forwards+0x0/0xcf > [] mark_lock+0x2ea/0x520 > [] __lock_acquire+0x6c1/0x1607 > [] ? radix_tree_delete+0xd1/0x1d0 > [] lock_acquire+0x57/0x6d > [] ? xfs_ilock+0x27/0x79 > [] down_write_nested+0x2a/0x4d > [] ? xfs_ilock+0x27/0x79 > [] xfs_ilock+0x27/0x79 > [] xfs_ireclaim+0x93/0xb1 > [] xfs_reclaim_inode+0x1de/0x20a > [] xfs_inode_ag_walk+0x8b/0xe6 > [] ? xfs_reclaim_inode+0x0/0x20a > [] xfs_inode_ag_iterator+0x80/0xd3 > [] ? xfs_reclaim_inode+0x0/0x20a > [] xfs_reclaim_inode_shrink+0x61/0x128 > [] shrink_slab+0xd3/0x144 > [] balance_pgdat+0x365/0x59b > [] ? isolate_pages_global+0x0/0x212 > [] kswapd+0x1f2/0x20f > [] ? autoremove_wake_function+0x0/0x34 > [] ? _raw_spin_unlock_irqrestore+0x5b/0x60 > [] ? kswapd+0x0/0x20f > [] kthread+0x7a/0x82 > [] kernel_thread_helper+0x4/0x10 > [] ? restore_args+0x0/0x30 > [] ? kthread+0x0/0x82 > [] ? 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@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs