Re: security: lockless stat() issues

[Al Viro <viro@ZenIV.linux.org.uk>]

On Fri, Oct 04, 2013 at 01:49:13PM -0700, Linus Torvalds wrote:
> That would get ugly.
> 
> However, I don't think we actually really need to do that.  We had a
> similar situation with d_revalidate() passing inode pointers etc
> totally unnecessarily. Yes, the filesystem needs to use ACCESS_ONCE()
> and care about NULL, but it doesn't need anything more than that. And
> we really do have that already.

Not for ->getattr()...  BTW, ->permission() for btrfs in that series
relies on not getting a MAY_WRITE | MAY_NOT_BLOCK combination, and
if you are serious about access(2), we'll need to lazy-delay freeing
struct btrfs_root.  Besides, we'll need to audit all ->permission()
instances for places that do not check for MAY_NOT_BLOCK on such
branches...

> And we already have dentry->d_sb - which is supposed to be valid.
> Again, we already use it under RCU for d_revalidate() and for name
> hashing. So the super-block had better already be ok with RCU.

Umm...  Right you are, so we really need to make freeing these suckers
delayed.  Fixed and pushed.  BTW, I wonder how much does removal of
s_files (next-to-last commit in #experimental) affect scalability on
open/close...  Anybody with perf setup and reasonable amount of
previous data?

BTW^2: what's the FM2R for perf testing of that kind?  E.g. how much
is testable under KVM, etc.?