[OpenAFS] Re: [OpenAFS-announce] OpenAFS client crashes on RHEL 5.10 and RHEL 6.5

[Andrew Deason]

[Moving from openafs-info to openafs-devel.]

On Tue, 11 Mar 2014 11:45:47 -0400
"J. Bruce Fields" <bfields@redhat.com> wrote:

> 	- d_materialise_unique: which was originally designed which
> 	  distributed filesystems in mind, which have the special issue
> 	  that the directory tree can be modified by other nodes without
> 	  their knowledge, so they need to be ble to deal with lookup
> 	  encountering an inode which was previously known under some
> 	  other name.

I'm not clear on if this really helps, as I'm not completely sure what
the effects of this are, but maybe you can clarify. It seems to just
'move' the dentry from one location to another, but I'm not sure if
that's all. Say we have the following AFS mountpoints (which appear as
directories, not e.g. vfsmounts or anything like that). These can be
anywhere in the hierarchy:

/afs/.../parent1/dir1
/afs/.../parent2/dir2

'dir1' and 'dir2' are AFS mountpoints to the same place. So, they are
effectively the same directory.

So if someone accesses dir1, say they have a reference to dentry
0x1234, which has d_name "dir1" and d_parent pointing to parent1.
And say someone accesses dir2 while dir1 is still held open. With
d_materialise_unique, it looks like they also get dentry 0x1234, but it
is 'moved' so now its d_name is "dir2" and its d_parent points to
parent2. Is that correct?

It seems like that does not get rid of the problem, since someone (call
it P1) could lookup dir1, and get back dentry 0x1234. Then someone else
looks up dir2 and renames/moves dentry 0x1234. P1 now has a reference to
dentry 0x1234, whose d_parent does not match the parent1, the directory
where we looked up 'dir1'. As we've seen, that can cause a panic on the
box (I'm glossing over how, if it's not readily apparent I can go into
more detail.)

I would also guess this causes an ELOOP error when trying to access a
mountpoint inside itself. That is maybe not the worst thing in the
world, but does preclude access which was previously allowed.

And just to be clear, I wasn't really expecting there to be some other
function to call that would make all of this "okay". I am working on
something to use actual mount points (that is, not "AFS mountpoints",
but 'struct vfsmount'/'struct mount' mountpoints). It is just a little
difficult since we cannot use the builtin kernel functions to create new
mountpoints.

> PS: feel free to redirect me to the correct list if this isn't it.

Moving to openafs-devel; please send replies there.

-- 
Andrew Deason
adeason@sinenomine.net