linux-kernel - Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks

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]

Message-ID: <20150515234936.GK7232@ZenIV.linux.org.uk>
Date:	Sat, 16 May 2015 00:49:36 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	NeilBrown <neilb@...e.de>
Cc:	Andreas Dilger <adilger@...ger.ca>,
	Dave Chinner <david@...morbit.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU
 symlinks

On Sat, May 16, 2015 at 09:30:22AM +1000, NeilBrown wrote:

> .. and I've been wondering what to do about i_mutex and NFS.  I've had
> customer reports of slowness in creating files that seems to be due to
> i_mutex on the directory being held over the whole 'create' RPC, so only one
> of those can be in flight at the one time.
> "make  -j" on a large source directory can easily want to create lots of
> "*.o" files at "the same time".
> 
> And NFS doesn't need i_mutex at all because the server will provide the
> needed guarantees.

Directory i_mutex is used for a lot more than serialization of fs methods
on said directory - a lot of dcache handling relies upon having it held
around adding dentries/moving them around/making them negative/etc.

Server can't do a damn thing about those, obviously.  Neither can it
do anything about multiple lookups on the same name in the same directory,
just because several processes have arrived at the same time with dcache
cold.  And no, caching dentry before the end of lookup isn't a good idea
either - you'll get tons of messy corner cases.

If anyone has a usable finer-grained locking scheme, I would _love_ to see it.
All I'd seen from Lustre folks in that area was bringing Stross' mythos to
mind - both as in "reduction of NP to P would be handy for analysis" and
"looking into that thing feels like an excellent way of inviting the gibbering
monstrosities from beyond the spacetime to chew on your cortex".
--
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/