linux-kernel - Re: [PATCH 0/3] Fixes for vfs-scale and vfs-automount

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] [day] [month] [year] [list]

Message-ID: <1298603266.3439.44.camel@perseus>
Date:	Fri, 25 Feb 2011 11:07:46 +0800
From:	Ian Kent <raven@...maw.net>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Trond Myklebust <Trond.Myklebust@...app.com>,
	David Howells <dhowells@...hat.com>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
	npiggin@...il.com
Subject: Re: [PATCH 0/3] Fixes for vfs-scale and vfs-automount

On Thu, 2011-02-24 at 14:59 +0000, Al Viro wrote:
> On Thu, Feb 24, 2011 at 06:07:33PM +0800, Ian Kent wrote:
> > > I really don't like the look of autofs4_tree_busy(), BTW - you don't need
> > > RCU to get races here; just a plain chdir("../../.."); done by a process
> > > that sits deep enough in subtree you are checking can very well race with
> > > your check, so that your iterator gets through the new cwd before chdir()
> > > and through the old one after it...
> > 
> > Yes, that's a problem.
> > 
> > Previously the dcache_lock would have blocked on the dput() ... mmm, I'd
> > missed that so far, although Nick didn't talk with me about his changes
> > very much at all and I didn't pay enough attention to his patch series
> > along the way, oops!
> 
> Well...  In principle, you could mark all mountpoints in a tree as managed,
> have an "expiry search in progress" flag to stop everything in there while
> the expiry happens, then wait out all RCU walks in progress, then go ahead
> with your expiry checks.  Would that work for you?

That approach would solve the problem.

It was deliberate to not make all dentrys as managed to avoid function
calls to ->manage() where possible but that might not be possible.

The priority right now though is the BUG() I'm getting due to the
elevated reference.

It turns out that the missing dput() you spotted won't trigger unless
user space does something stupid and that's why it didn't show up in
testing before.

Anyway, recent printk output is pointing me at do_filp_open() so I'm
probably going to need to look closely at it. I'm still gathering printk
evidence but I think that pain is coming.

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/