From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: lockdep warning with 2.6.29-rc6-mm1 (mmotm 24-feb-2009) Date: Wed, 04 Mar 2009 14:27:47 +0100 Message-ID: <1236173267.5330.7487.camel@laptop> References: <20090304125709.GA6251@balbir.in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Andrew Morton , "linux-kernel@vger.kernel.org" , Ingo Molnar , Nick Piggin , Eric Paris , linux-fsdevel To: balbir@linux.vnet.ibm.com Return-path: Received: from bombadil.infradead.org ([18.85.46.34]:44552 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750760AbZCDN2P (ORCPT ); Wed, 4 Mar 2009 08:28:15 -0500 In-Reply-To: <20090304125709.GA6251@balbir.in.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, 2009-03-04 at 18:27 +0530, Balbir Singh wrote: > I see the following on my machine. My understanding is that the > lockdep warning is complaining about a potential deadlock while > reclaiming, where we could end up waiting on holding inotify_mutex, > and we could end up calling reclaim with inotify_mutex held. > > The race seems rare, since one path shows a new inode being created > and the other one being deleted. It seems like a false positive unless > the inode's in question turn out to be potentially the same. Its not a false positive until you can guarantee the inodes will _never_ be the same. This thing has been reported numerous times, Ingo even posted a potential fix for it, Nick poked the inotify people to speak up, but they have so far been silent on the issue :-( Eric, can you help us out?, you seem to be the one who touched it last :-) If this is an inode life-time thingy, where there is a clear distinction between active inodes and inactive (ready to be reclaimed) inodes, the proper annotation would be to move inode->inotify->mutex in a different class whenever this transition takes place. [ small note to everybody mailing lockdep splats, please don't word wrap them ] > ================================= > [ INFO: inconsistent lock state ] > 2.6.29-rc6-mm1-g3d748a4-dirty #36 > --------------------------------- > inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage. > yum-updatesd-he/4004 [HC0[0]:SC0[0]:HE1:SE1] takes: > (&inode->inotify_mutex){+.+.?.}, at: [] inotify_inode_queue_event+0x4f/0xe0 > {IN-RECLAIM_FS-W} state was registered at: > [] __lock_acquire+0x640/0x7ec > [] lock_acquire+0x85/0xa9 > [] mutex_lock_nested+0x5b/0x2d9 > [] inotify_inode_is_dead+0x29/0x90 > [] dentry_iput+0x7c/0xbb > [] d_kill+0x50/0x71 > [] __shrink_dcache_sb+0x21c/0x2c3 > [] shrink_dcache_memory+0xfe/0x18e > [] shrink_slab+0x114/0x192 > [] kswapd+0x38b/0x593 > [] kthread+0x88/0x92 > [] child_rip+0xa/0x20 > [] 0xffffffffffffffff > irq event stamp: 220969 > hardirqs last enabled at (220969): [] kmem_cache_alloc+0xa2/0xca > hardirqs last disabled at (220968): [] __slab_alloc+0x1fa/0x3ed > softirqs last enabled at (219310): [] __do_softirq+0x16e/0x17b > softirqs last disabled at (219305): [] call_softirq+0x1c/0x34 > > other info that might help us debug this: > 4 locks held by yum-updatesd-he/4004: > #0: (&type->i_mutex_dir_key#4){+.+.+.}, at: [] do_filp_open+0x181/0x7cf > #1: (&inode->inotify_mutex){+.+.?.}, at: [] inotify_inode_queue_event+0x4f/0xe0 > #2: (&ih->mutex){+.+...}, at: [] inotify_inode_queue_event+0x7d/0xe0 > #3: (&dev->ev_mutex){+.+...}, at: [] inotify_dev_queue_event+0x36/0x155 > > stack backtrace: > Pid: 4004, comm: yum-updatesd-he Not tainted > 2.6.29-rc6-mm1-g3d748a4-dirty #36 > Call Trace: > [] print_usage_bug+0x1b6/0x1c7 > [] ? check_usage_backwards+0x0/0x9e > [] mark_lock+0x305/0x58c > [] ? kernel_event+0xaa/0x116 > [] mark_held_locks+0x49/0x69 > [] lockdep_trace_alloc+0x75/0x77 > [] __kmalloc+0x61/0x10a > [] kernel_event+0xaa/0x116 > [] inotify_dev_queue_event+0xda/0x155 > [] inotify_inode_queue_event+0xab/0xe0 > [] vfs_create+0xb3/0xc3 > [] do_filp_open+0x248/0x7cf > [] ? alloc_fd+0x10f/0x11e > [] ? _spin_unlock+0x26/0x2a > [] do_sys_open+0x53/0xda > [] sys_open+0x1b/0x1d > [] system_call_fastpath+0x16/0x1b