From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757516Ab0AOMog (ORCPT ); Fri, 15 Jan 2010 07:44:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757157Ab0AOMoe (ORCPT ); Fri, 15 Jan 2010 07:44:34 -0500 Received: from bld-mail19.adl2.internode.on.net ([150.101.137.104]:49178 "EHLO mail.internode.on.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1757171Ab0AOMod (ORCPT ); Fri, 15 Jan 2010 07:44:33 -0500 Date: Fri, 15 Jan 2010 23:44:10 +1100 From: Dave Chinner To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, mingo@redhat.com Subject: Re: lockdep: inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-R} usage. Message-ID: <20100115124410.GI28498@discord.disaster> References: <20100115120253.GH28498@discord.disaster> <1263557473.4244.399.camel@laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1263557473.4244.399.camel@laptop> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 15, 2010 at 01:11:13PM +0100, Peter Zijlstra wrote: > On Fri, 2010-01-15 at 23:02 +1100, Dave Chinner wrote: > > Just got this on a 2.6.33-rc3 kernel during unmount: > > > > [21819.329256] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-R} usage. > > [21819.349943] kswapd0/407 [HC0[0]:SC0[0]:HE1:SE1] takes: > > [21819.349943] (iprune_sem){+++++-}, at: [] shrink_icache_memory+0x82/0x2b0 > > [21819.349943] {RECLAIM_FS-ON-W} state was registered at: > > [21819.349943] [] mark_held_locks+0x73/0x90 > > [21819.349943] [] lockdep_trace_alloc+0xc5/0xd0 > > [21819.349943] [] kmem_cache_alloc+0x41/0x150 > > [21819.349943] [] kmem_zone_alloc+0x99/0xe0 > > [21819.349943] [] kmem_zone_zalloc+0x1e/0x50 > > [21819.349943] [] _xfs_trans_alloc+0x38/0x80 > > [21819.349943] [] xfs_trans_alloc+0x9f/0xb0 > > [21819.349943] [] xfs_free_eofblocks+0x120/0x290 > > [21819.349943] [] xfs_inactive+0x103/0x560 > > [21819.349943] [] xfs_fs_clear_inode+0xdf/0x120 > > [21819.349943] [] clear_inode+0xb5/0x140 > > [21819.349943] [] dispose_list+0x38/0x130 > > [21819.349943] [] invalidate_inodes+0x123/0x170 > > [21819.349943] [] generic_shutdown_super+0x4e/0x100 > > [21819.349943] [] kill_block_super+0x31/0x50 > > [21819.349943] [] deactivate_super+0x85/0xa0 > > [21819.349943] [] mntput_no_expire+0xca/0x110 > > [21819.349943] [] sys_umount+0x64/0x370 > > [21819.349943] [] system_call_fastpath+0x16/0x1b > > [21819.349943] irq event stamp: 4151539 > > [21819.349943] hardirqs last enabled at (4151539): [] _raw_spin_unlock_irqrestore+0x44/0x70 > > [21819.349943] hardirqs last disabled at (4151538): [] _raw_spin_lock_irqsave+0x25/0x90 > > [21819.349943] softirqs last enabled at (4151312): [] __do_softirq+0x18b/0x1e0 > > [21819.349943] softirqs last disabled at (4150645): [] call_softirq+0x1c/0x50 > > [21819.349943] > > [21819.349943] other info that might help us debug this: > > [21819.349943] 1 lock held by kswapd0/407: > > [21819.349943] #0: (shrinker_rwsem){++++..}, at: [] shrink_slab+0x3d/0x180 > > [21819.349943] > > [21819.349943] stack backtrace: > > [21819.349943] Pid: 407, comm: kswapd0 Not tainted 2.6.33-rc3-dgc #35 > > [21819.349943] Call Trace: > > [21819.349943] [] print_usage_bug+0x183/0x190 > > [21819.349943] [] mark_lock+0x342/0x420 > > [21819.349943] [] ? check_usage_forwards+0x0/0x100 > > [21819.349943] [] __lock_acquire+0x4d1/0x17a0 > > [21819.349943] [] ? __lock_acquire+0x21f/0x17a0 > > [21819.349943] [] lock_acquire+0xce/0x100 > > [21819.349943] [] ? shrink_icache_memory+0x82/0x2b0 > > [21819.349943] [] down_read+0x52/0x90 > > [21819.349943] [] ? shrink_icache_memory+0x82/0x2b0 > > [21819.349943] [] shrink_icache_memory+0x82/0x2b0 > > [21819.349943] [] shrink_slab+0x12a/0x180 > > [21819.349943] [] kswapd+0x586/0x990 > > [21819.349943] [] ? isolate_pages_global+0x0/0x240 > > [21819.349943] [] ? autoremove_wake_function+0x0/0x40 > > [21819.349943] [] ? kswapd+0x0/0x990 > > [21819.349943] [] kthread+0x96/0xa0 > > [21819.349943] [] kernel_thread_helper+0x4/0x10 > > [21819.349943] [] ? restore_args+0x0/0x30 > > [21819.349943] [] ? kthread+0x0/0xa0 > > [21819.349943] [] ? kernel_thread_helper+0x0/0x10 > > > > I can't work out what the RECLAIM_FS notations are > > supposed to mean from the code and they are not documented at > > all, so I need someone to explain what this means before I can > > determine if it is a valid warning or not.... > > The RECLAIM_FS bit means that lock (iprune_sem) was > taken from reclaim and is also taken over an allocation. So there's an implicit, undocumented requirement that inode reclaim during unmount requires a filesystem to do GFP_NOFS allocation? Cheers, Dave. -- Dave Chinner david@fromorbit.com