Re: semantics of TRYEMULROOT

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

On Sun, Jan 02, 2011 at 06:14:57PM +0000, David Laight wrote:
 > On Sun, Jan 02, 2011 at 09:52:31AM +0000, David Holland wrote:
 > > Has anyone ever sat down and clearly worked out the desired semantics
 > > for TRYEMULROOT? I've noted inconsistencies in the past, and because
 > > in a number of ways it's a special case of onionfs I'm somewhat
 > > concerned that there may be cases where the proper or desired behavior
 > > is unclear or ambiguous.
 > 
 > When I added TRYEMULROOT I did so in order to maintain the same actions
 > as the old code - which did all sorts of horrid checks before copying
 > a changed path out into the stackgap.
 > At that time I didn't want to be worried about which code paths should,
 > or should not, look in the emulated root - since many of the emulations
 > were probably broken.

That's more or less what I thought :-)

 > You are probably the only one who has actually looked into this deeply!
 > It does seem likely that only ENOENT (and similar) should cause the
 > main fs to be checked.

Yeah, but which are similar? Clearly e.g. ENOTDIR, maybe ELOOP; one
could make a case either way for EROFS and EACCES though. And some
things that might turn up, like ESTALE or ECONNTIMEDOUT, aren't clear
at all...

The question of where to commit to an object to work with is more
important than the precise list of errors to retry on, because the
former is structural and the latter is (relatively) cosmetic.

Currently operations like mkdir do (roughly)

   NDINIT(&nd, CREATE, LOCKPARENT, path);
   namei(&nd);
   if (nd.ni_vp != NULL) {
        return EEXIST;
   }
   VOP_MKDIR(nd.ni_dvp, &nd.ni_cnd);
   vput(nd.ni_dvp);

but the plan is to change this to (roughly)

   char last[NAME_MAX];
   namei_parent(path, &dvp, last, sizeof(last));
   vn_lock(dvp);
   VOP_MKDIR(dvp, last);
   vn_unlock(dvp);
   vrele(dvp);

which is simpler and a lot tidier, both on the surface and inside the
fs; however, if TRYEMULROOT is wanted it's obviously not desirable to
need a retry loop here (and in each of the several other similar
functions) -- therefore I'd like namei_parent to be able to commit to
a (parent) directory to operate in, handling TRYEMULROOT inside itself
only. In addition to fitting my design better I think this provides a
more consistent semantics; I just want to make sure we think it'll
work before committing to it.

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