1) paths involving @sys: when the afs client processes a pathname component that contains the string @sys, it internally replaces the @sys with the current sysname value (or, if multiple sysname values are configured, it iterates over them until it finds a matching name). afs_linux_lookup then d_add()'s the returned inode with the callers dentry (which contains the untranslated string). If some other operation looks up the "real" name, that name also gets d_add()'d with the same inode object.
2) multiply-mounted volumes. A similar thing happens when a volume is mounted in more than one location. The volume root (and it's children) is the same vcache/vnode/inode wherever it is mounted, but each mountpoint will have a unique dentry.
I actually encountered a hang as a result of this situation, where lock_rename() downed the same semaphore twice.
I have a patch for this that seems to work, but I'd like some of the other linux-aware people on the list to look it over and let me know if my use of d_find_alias is appropriate here or if I should be doing something else. Suggestions for what conditional I should be using would be welcome.
<http://www.contrib.andrew.cmu.edu/~cg2v/openafs-patches/osi_vn_alias.diff>
It has been requested that I try to make sure that the (one and only) dentry never has the @sys name in it. The only way we came up to do this is to extend the afs_lookup() interface to return the translated name if @sys processing was done. Does this seem appropriate?
p7sWpzEjyT7Wm.p7s
Description: S/MIME cryptographic signature
