From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Subject: Re: [RFC PATCH] shrink_dcache_parent() deadlock Date: Mon, 9 Jan 2012 09:16:52 -0800 Message-ID: <20120109171652.GA3904@suse.de> References: <87ipkl87m9.fsf@tucsk.pomaz.szeredi.hu> <877h10957n.fsf@tucsk.pomaz.szeredi.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Linus Torvalds , viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, mgorman@suse.de, hch@infradead.org, akpm@linux-foundation.org To: Miklos Szeredi Return-path: Received: from cantor2.suse.de ([195.135.220.15]:41827 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932266Ab2AIRRC (ORCPT ); Mon, 9 Jan 2012 12:17:02 -0500 Content-Disposition: inline In-Reply-To: <877h10957n.fsf@tucsk.pomaz.szeredi.hu> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Jan 09, 2012 at 06:05:32PM +0100, Miklos Szeredi wrote: > Linus Torvalds writes: >=20 > > On Mon, Jan 9, 2012 at 2:58 AM, Miklos Szeredi = wrote: > >> > >> This patch adds a new dentry flag that is set when the dentry is r= emoved > >> from the lru and put on the list being processed by > >> shrink_dentry_list(). =A0The flag is cleared in dentry_lru_del() w= hich is > >> called if the dentry gets a new reference just before it's pruned. > >> > >> Thoughts? > > > > Looks reasonable. Were you actually able to reproduce the hang, or = how > > did you notice? >=20 > We got a bug report from a partner about hang during reboot. It's > actually quite easily reproducible with: >=20 > while true; do > echo -bond0 > /sys/class/net/bonding_masters > echo +bond0 > /sys/class/net/bonding_masters > echo -bond1 > /sys/class/net/bonding_masters > echo +bond1 > /sys/class/net/bonding_masters > done >=20 > That reliably triggers the soft lookup detector for several machines > that we tested. It's rather timing sensitive though, because turning= on > DEBUG_SPINLOCK makes it go away. >=20 > I had to add printks to see what's going on, because it wasn't obviou= s > from the stack traces and crash dumps. You also usually need to add a udev rule that looks at the pci id of th= e device as well, without checking for what type it is (which is what a "correct" udev rule should be doing, which is why we only started seein= g this on some systems, with "incorrect" rules.) Having a file in /lib/udev/rules.d/ with only this one rule: ATTR{vendor}=3D=3D"0x8086", ATTR{device}=3D=3D"0x10ca", ENV{PCI_SLOT_NA= ME}=3D"%k", ENV{MATCHADDR}=3D"$attr{address}", RUN+=3D"/bin/true" Seems to do the trick. udev calls stat() on the vendor sysfs file, while it is going away, and then this dentry race shows up. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html