misuse of pathnames in rump (and portalfs?)

[David Holland <dholland-tech%netbsd.org@localhost>]

I have run into a problem fixing namei.

First, background: VOP_LOOKUP is the per-fs vnode operation that takes
a directory and a name and returns the vnode associated with that
name. This currently has a horrific interface and the chief goal of
the namei cleanup is to rectify this so all it needs is a vnode and a
string.

However, I discovered today that rumpfs's VOP_LOOKUP implementation
relies on being able to access not just the name to be looked up, but
also the rest of the pathname namei is working on, specifically
including the parts that have already been translated. (This is
currently possible by misusing struct componentname; the patch I've
been working on makes that impossible.)

It appears that the rump code is assuming that the string it gets is
an absolute or canonical path so it can use it as a lookup key. This
is wrong -- the string it's using might be absolute but might not,
and depends on the specific pathname given to namei and which symlinks
have been traversed. This, as far as I can tell, makes the rump code
wrong.

Furthermore, it is just plain gross for the behavior of VOP_LOOKUP in
some directory to depend on how one got to that directory. As a matter
of design, the working path should not be available to VOP_LOOKUP and
VOP_LOOKUP should not attempt to make use of it.

When I asked pooka for clarification, I got back an assertion that
portalfs depends on this behavior so I should rethink the namei design
to support it. However, as far as I can tell, this is not true: there
is only one unexpected/problematic use of the pathname buffer in
question anywhere in the system, in rumpfs.c. Furthermore, even if it
were true, I think it would be highly undesirable.

So:

(1) does anyone think that a correct namei design should provide the
namei pathname scratch space to the FS for its inspection during
lookup?

(2) does anyone think that a correct namei design should provide a
correct canonicalized full pathname for its inspection during lookup?
(Note that this is free -- it would require splicing a getcwd into
every namei call.)

(3) Does anyone object if, as a way forward, I add an extra argument
const char *partialpath to VOP_LOOKUP to provide the string that rump
wants, until rump is fixed, and then revert it?

(4) vermilion.

-- 
David A. Holland
dholland%netbsd.org@localhost