[OpenAFS-devel] getcwd() on Linux 2.6.18+OpenAFS 1.4.2 bugs/errors.

[Michael Loftis]

--On November 9, 2007 9:50:30 AM -0500 Jim Rees <rees@umich.edu> wrote:

> Sorry for the sloppy language.  I'll try to be more formal.
>
> I think what you're asking for is the ability to have undirected cycles in
> the namespace, while prohibiting traversals toward the root except by the
> path that took you to a particular place.
>
> I think this is going to be hard to do in afs.  It more properly belongs
> in the vnode layer (or whatever passes for that in your OS of choice).
> Afs currently keeps a single parent pointer in the vcache.  You would
> instead need a list of these, and information about which one to choose.
> That information has to be available to afs_lookup.

In Linux atleast, the VFS lookup routine I believe is given this 
information, eg afs_linux_lookup should have it available when it sees 
it....

Whats weirder is occasionally via the Linux stat call i get different inode 
numbers between two calls, I haven't been able to reliable reproduce that 
behavior though....

so....thinking out loud a lot here....with a partially incomplete 
understanding of the AFS guts.

readdir on a parent is returning a string representation, or, in some other 
manner we figure out what we're looking for (quite possibly guessing, EG 
with a  "deep" cd or something so) eventually we call lookup with that 
string, "var", and the parent information visible to the lookup routine, 
AFS discards this information at some point after using it to find what 
we're looking for, and instead returns a reference to something with a 
different parent, assuming that object was cached beforehand, and we're 
looking up from a different parent.  To the kernel, it sees the same inode 
number....

> The problem is that afs_lookup has no way of knowing which one to choose.
> All it has is a vnode pointer, which will be the same for each of the
> possible parents.  It's also got creds and it knows what user process it's
> running in, so I guess it could be done per-user or per-process if that's
> good enough for you, although this would be tricky to get right.

afs_lookup is passed a string to look for, and the information of the 
parent that entry should (may) occur in...now...this is where i'm getting a 
bit deep, but, it should be able to realize/compare/see/something when the 
entry it's about to return has a parent different than the current 
dir/parent info it was given....now how that interacts with the guts of AFS 
i'm not certain.  And this is mostly of concern in the special case where 
we're processing a mount point.

so instead of fixing it in lookup of ./.. ... maybe it should be fixed in 
lookup of a mount point or symlink and what/how that's being returned as an 
inode to the kernel?  or data afs is tagging to that inode?

>
> Kolya's suggestion was to allocate different vnodes each time a mount
> point is looked up from a new parent.  Presumably the vcache would have a
> list of parent vcaches and corresponding vnodes.  That would violate one
> of the fundamental assumptions of the vnode layer, that identical objects
> have the same vnode.  But since we're only talking about directories,
> maybe it would work.

Hmmm...Well, not really directories, mount points, but AFS presents them to 
the kernel as directories....though...from the rest of this thread the same 
problem exists in similar fashions....i'm less worried about how symlinks 
get resolved than i am about the ".." following going on that gets out of 
jails and such....

> I'd also be curious what would happen if the path you took to get to some
> place went away.  I guess you would be orphaned.  Is that what you want?

Well, what happens *now*?  That result is no different than process 1 going 
into some mount and someone else executing fs rmm on the mount, or if it's 
a regular directory, executing rmdir/unlink/whatever on the directory. 
That'd be happening now....



I think i need to sit back and have a deep think on this, but it doesn't 
seem like it should be complicated to manage.  The information is *given* 
by the VFS layer when it asks for a lookup, all AFS needs to do is use it 
properly I think...it ... may mean somehow remembering to "fixup" . and .. 
whenever readdir is called, which could only be done by tagging...returning 
different data(inode number....?) for each "view" of a mount point i 
suppose....

I'm just not sure how all of it should interact, but...it seems like 
there's a way to make this work without fscking the guts of the AFS 
implementation.....i jsut...really don't understand the vcache well enough 
right now to see it, nor how those lookups get resolved out of the cache.