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]

Date:	Wed, 13 May 2015 20:52:59 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Christoph Hellwig <hch@...radead.org>,
	Neil Brown <neilb@...e.de>
Subject: Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks

On Wed, May 13, 2015 at 8:30 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Maybe...  I'd like to see the profiles, TBH - especially getxattr() and
> access() frequency on various loads.  Sure, make(1) and cc(1) really care
> about stat() very much, but I wouldn't be surprised if something like
> httpd or samba would be hitting getxattr() a lot...

So I haven't seen samba profiles in ages, but iirc we have more
serious problems than trying to speed up basic filename lookup.

At least long long ago, inode semaphore contention was a big deal,
largely due to readdir(). And readdir() itself, for that matter - we
have no good vfs-level readdir caching, so it all ends up serialized
on the inode semaphore, and it all goes all the way into the
filesystem to get the readdir data. And at least for ext4, readdir()
is slow anyway, because it doesn't use the page cache, it uses that
good old buffer cache, because of how ext4 does metadata journaling
etc.

Having readdir() caching at the VFS layer would likely be a really
good thing, but it's hard. It *might* be worth looking at the nfs4
code to see if we could possibly move some of that code into the vfs
layer, but the answer is likely "no", or at least "that's incredibly
painful".

Also, I *think* samba ends up basically doing most of the pathname
lookups from its own user-level cache, because of how it needs to
avoid symlinks and do the whole crazy case insensitive pathname thing.
I have this very dim memory that that's one reason samba ends up being
so readdir-intensive. But I might be wrong, it's been many years since
I talked to anybody about samba, and I don't run it myself.

But yes, that would likely be a very worthy profile target. I suspect
we've beaten the "make does lots of stat() calls" horse pretty much to
death.

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