[lkml]   [2015]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] freeing unlinked file indefinitely delayed
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.

 \ /
  Last update: 2015-07-12 17:21    [W:0.045 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site