From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [RFC PATCH] shrink_dcache_parent() deadlock Date: Tue, 10 Jan 2012 16:15:17 +0000 Message-ID: <20120110161516.GB23916@ZenIV.linux.org.uk> References: <87ipkl87m9.fsf@tucsk.pomaz.szeredi.hu> <20120109171639.GA9359@infradead.org> <20120109173010.GX23916@ZenIV.linux.org.uk> <20120109205907.GE4198@dastard> <20120110013434.GA23916@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Miklos Szeredi , Dave Chinner , Christoph Hellwig , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, mgorman@suse.de, gregkh@suse.de, akpm@linux-foundation.org To: Linus Torvalds Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, Jan 10, 2012 at 08:00:30AM -0800, Linus Torvalds wrote: > On Tue, Jan 10, 2012 at 2:05 AM, Miklos Szeredi wrote: > > > > I tested Dave's patch and the bug can still be easily reproduced. > > > > And that's to be expected, as the intermediate "being on the lru" > > state that Dave's patch eliminates doesn't play a fundamental part in > > the mechanism of the livelock. ?It does eliminate one trylock, but > > that's not the one critical to this bug (removing it is a very good > > idea anyway). > > > > The critical trylock here is the one in dentry_kill() which tries to > > lock the parent. > > Ok. Here's your patch munged for current -git. You've got most of a > changelog, can you send this out with the right subject and a > sign-off, and re-test with the current git just to make sure. > > Al, do you want to handle this or should I take it directly? I'll pick it once Miklos posts it. > I'm assuming nobody has any objections to Miklos' patch? I'm fine with it. ObGrrr: I'm down to two remaining d_alloc_root() callers and while neither is buggy per se, looking around a bit has turned up breakage in both cases ;-/ (coda lookup treating OOM in new_inode() as "not found" rather than -ENOMEM and hfs+ mount not bothering to check if allocation *or* disk IO might fail, with very ugly results)...