linux-kernel - Re: VFS + path walktrough

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:	Mon, 05 May 2008 19:33:00 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	viro@...IV.linux.org.uk
CC:	miklos@...redi.hu, weigelt@...ux.de, linux-kernel@...r.kernel.org
Subject: Re: VFS + path walktrough

> > One way this could be done cleanly, is to pass the rest of the path
> > (as hint) to the filesystem in its lookup function.  Most filesystems
> > would just ignore it, but those which have the capabilities can use it
> > to do the lookup in one go, and internally cache the result.  The VFS
> > doesn't need to know _anything_ about all this.  If there are
> > mountpoints, they are already cached, so ->lookup() wouldn't be called
> > at all, only ->d_revalidate(), which is a different issue.
> 
> This is still wrong.  We not just pass the pathname to filesystem (note
> that you still need to deal with symlinks),

Symlinks are easy: filesystem just needs to *stop* the resolution the
moment it finds one.

> but we make that filesystem to populate dentry tree.

Doesn't sound hard: d_alloc() + d_instantiate().

>  Take a look at 9P walk - it does *not* give
> you anything resembling stat, you just get qids of intermediates.

Which is exactly what's needed to populate the dentry tree, no?

>  Which
> is bloody useful when you want to do intelligent revalidation (do local
> cached walk, then issue a single protocol request that will both do
> bulk revalidate *and* tell you where in the path you've got the first
> invalid one - just compare qids with what you've got stored locally).
> However, it's just about useless for cutting corners in cold-cache
> lookup.

Sure, it's useful for that as well.

> It _is_ a useful thing, no arguments about that.  However, to use it
> a sane way we need to massage the pathname resolution loop, taking
> the "simple pass without symlinks or mountpoints" part into a new
> helper, turning the current __link_path_walk() into a loop calling that
> one and then folding it into callers.  Would also allow to kill the
> last remnants of recursion in symlink handling for normal fs case...
> 
> _Then_ we can do saner logics for revalidate, allowing it on such segments.
> Which, BTW, would deal with -ESTALE in a saner way, rather than "repeat
> full pathname resolution from the very beginning".  And that's where
> 9P multi-step walk(5) would do very nicely, indeed.

Sounds wonderful.  Really.

> And fuck the "hints" of all kinds, pardon the rudeness.

Don't mind at all.  In fact I usually enjoy it.

>  We already have more than enough of that crap and it already makes
> cleaning the logics up bloody painful.

Separate i_op for it is fine by me as well.

Not that I care very much.  I have plans for such a bulk lookup
interface in fuse, but that's far in the future.

Miklos

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