Date: Sun, 12 Jul 2015 16:17:29 +0100
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Ian Kent <raven@themaw.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
        "J. Bruce Fields" <bfields@fieldses.org>, linux-kernel@vger.kernel.org,
        linux-fsdevel@vger.kernel.org
Subject: Re: [RFC] freeing unlinked file indefinitely delayed
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
Content-Disposition: inline
In-Reply-To: <1436441204.2709.10.camel@pluto.fritz.box>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1209
Lines: 25

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/