linux-kernel - Re: [announce] vfs-scale git tree update

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:	Wed, 12 Jan 2011 12:41:19 +0800
From:	Ian Kent <raven@...maw.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	aelder@....com, Nick Piggin <npiggin@...nel.dk>,
	Al Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [announce] vfs-scale git tree update

On Tue, 2011-01-11 at 20:06 -0800, Linus Torvalds wrote:
> On Tue, Jan 11, 2011 at 7:59 PM, Ian Kent <raven@...maw.net> wrote:
> >
> > Isn't the parent i_mutex held during mkdir()?
> 
> Yes, but a lookup that hits in the dentry cache won't actually take
> the parent mutex.
> 
> So as far as I can tell, doing the "d_add()" before setting d_op can
> result in another CPU coming in and seeing the newly added dentry
> before d_op has actually been initialized. Exactly because it will do
> the dentry lookup without holding any mutex.
> 
> Of course, it's a very small window, so it probably doesn't matter in practice.
> 
> >> Looking at it quickly, I don't think that would matter for
> >> the case at hand.  I.e., that might be safer but it doesn't
> >> address the fact that these fields are getting initialized
> >> multiple times.
> >
> > Yeah, a hangover from changes done over time.
> > Not setting the dentry op in ->lookup() should fix this.
> 
> Alex, care to test just removing the d_set_d_op() call from autofs4_lookup()?
> 
> (That code is a bit scary, though - it explicitly makes it a negative
> dentry with a d_instantiate(dentry, NULL), and then hides the inode
> information away separately. Scary scary)

Yeah, but the expire to mount races with autofs are difficult to handle
and this approach has worked well under heavy stress testing. It's true
that this would almost certainly be bad for a file system that supported
a full range of functionality but that's not so for autofs.

> 
>               Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


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