linux-kernel - Re: [RFC] freeing unlinked file indefinitely delayed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 13 Jul 2015 10:30:25 +0800
From:	Ian Kent <raven@...maw.net>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [RFC] freeing unlinked file indefinitely delayed

On Sun, 2015-07-12 at 16:17 +0100, Al Viro wrote:
> 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.

Yep, that was what I was thinking at the time.

> 
> 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.

I get all of that, and it sure does look like these things should be
treated as unhashed.

My puzzle is the life cycle of DCACHE_DISCONNECTED dentrys, which is
mostly unrelated.

Not to worry, this isn't the first time I've been defeated trying to
work it out.

The only way I can see disconnected dentrys created (possibly unhashed,
and maybe not materialized) is via nfs and nfsd, beside the usage
mentioned here of course.

There must be some indirection I'm missing wrt. export_operations
usage ....

Ian

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