linux-kernel - Re: [PATCH -V14 0/11] Generic name to handle and open by handle syscalls

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:	Thu, 8 Jul 2010 04:05:07 +1000
From:	Nick Piggin <npiggin@...e.de>
To:	Andreas Dilger <andreas.dilger@...cle.com>
Cc:	"J. Bruce Fields" <bfields@...ldses.org>,
	"Aneesh Kumar K. V" <aneesh.kumar@...ux.vnet.ibm.com>,
	Neil Brown <neilb@...e.de>, hch@...radead.org,
	viro@...iv.linux.org.uk, adilger@....COM, corbet@....net,
	serue@...ibm.com, hooanon05@...oo.co.jp,
	linux-fsdevel@...r.kernel.org, sfrench@...ibm.com,
	philippe.deniel@....FR, linux-kernel@...r.kernel.org
Subject: Re: [PATCH -V14 0/11] Generic name to handle and open by handle
 syscalls

On Wed, Jul 07, 2010 at 11:02:47AM -0600, Andreas Dilger wrote:
> On 2010-07-07, at 09:05, J. Bruce Fields wrote:
> > On Wed, Jul 07, 2010 at 01:40:53AM -0600, Andreas Dilger wrote:
> >> On 2010-07-06, at 11:09, Aneesh Kumar K. V wrote:
> >>> Since we know that system wide file handle should include a file system
> >>> identifier and a file identifier my plan was to retrieve both in the
> >>> same syscall.
> >> 
> >> Won't having it be in a separate system call be racy w.r.t. doing the pathname lookup twice?
> > 
> > It'll be rare that a server will want to *just* get a filehandle;
> > normally it will at least want to get some attributes at the same time.
> > So I think it will always need to open the file first and then do the
> > rest of the operations on the returned filehandle.
> 
> I think you are assuming too much about the use of the file handle.  What I'm interested in is not a userspace file server, but rather a more efficient way to have 10000's to millions of clients to be able to open the same regular file, without having to do full path traversal for each one.

Really? What kind of clients? What sort of speedups do you hope to see?
Path traversal can get vastly cheaper in both single threaded and parallel
cases with my locking changes.

It is not acceptable to work around fixable deficiencies in our critical
infrastructure like path walking with hacks like this. If path walking
is still much too expensive, that's another story...

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