From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [RFC] freeing unlinked file indefinitely delayed Date: Sun, 12 Jul 2015 16:17:29 +0100 Message-ID: <20150712151729.GK17109@ZenIV.linux.org.uk> References: <20150708014237.GC17109@ZenIV.linux.org.uk> <1436440655.2709.8.camel@pluto.fritz.box> <1436441204.2709.10.camel@pluto.fritz.box> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Linus Torvalds , "J. Bruce Fields" , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org To: Ian Kent Return-path: Content-Disposition: inline In-Reply-To: <1436441204.2709.10.camel@pluto.fritz.box> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Jul 09, 2015 at 07:26:44PM +0800, Ian Kent wrote: > > But the dentrys that will most likely face summary execution will be > > hashed, such as was the case on that 2.6.32 kernel at dput(). > > > > Doesn't that mean that something dropped the dentry after the dput(), > > that will now also free the dentry, that took the refcount to 0? > > Oh wait, think I get it now ... perhaps it's prune_one_dentry() doing > it ... What, unhashing? Yes, it does. A bit of context - the breakage that had first pointed in direction of this bug had been a deadlock with dcache shrinker run on frozen fs was stumbling across a hashed dentry with zero refcount *and* zero link count of its inode, triggering its eviction, final iput(), inode freeing and deadlock on attempt to do sb_start_intwrite() there; figuring out how could such a dentry appear in the first place had uncovered this fun. Which a) is a bug in its own right and b) happens in mainline as well.