On Tue, Jun 03, 2008 at 03:53:36PM -0400, Jeff Moyer wrote: > autofs4_lookup is called on behalf a process trying to walk into an > automounted directory. That dentry's d_flags is set to > DCACHE_AUTOFS_PENDING but not hashed. A waitqueue entry is created, > indexed off of the name of the dentry. A callout is made to the > automount daemon (via autofs4_wait). > > The daemon looks up the directory name in its configuration. If it > finds a valid map entry, it will then create the directory using > sys_mkdir. The autofs4_lookup call on behalf of the daemon (oz_mode == > 1) will return NULL, and then the mkdir call will be made. The > autofs4_mkdir function then instantiates the dentry which, by the way, > is different from the original dentry passed to autofs4_lookup. (This > dentry also does not get the PENDING flag set, which is a bug addressed > by a patch set that Ian and I have been working on; specifically, the > idea is to reuse the dentry from the original lookup, but I digress). > > The daemon then mounts the share on the given directory and issues an > ioctl to wakeup the waiter. When awakened, the waiter clears the > DCACHE_AUTOFS_PENDING flag, does another lookup of the name in the > dcache and returns that dentry if found. > Later, the dentry gets expired via another ioctl. That path sets > the AUTOFS_INF_EXPIRING flag in the d_fsdata associated with the dentry. > It then calls out to the daemon to perform the unmount and rmdir. The > rmdir unhashes the dentry (and places it on the rehash list). > > The dentry is removed from the rehash list if there was a racing expire > and mount or if the dentry is released. > > This description is valid for the tree as it stands today. Ian and I > have been working on fixing some other race conditions which will change > the dentry life cycle (for the better, I hope). So what happens if new lookup hits between umount and rmdir? Another thing: would be nice to write down the expected state of dentry (positive/negative, flags, has/hasn't ->d_fsdata, flags on ->d_fsdata) for all stages. I'll go through the code and do that once I get some sleep, but if you'll have time to do it before that... FWIW, I wonder if it would be better to leave the directory alone and just have the daemon mount the sucker elsewhere and let the kernel side move the damn thing in place itself, along with making dentry positive and waking the sleepers up. Then we might get away with not unlocking anything at all... That obviously doesn't help the current systems with existing daemon, but it might be interesting for the next autofs version... Note that we don't even have to mount it anywhere - mount2() is close to the top of the pile for the next couple of cycles and it'd separate "activate fs" from "attach fully set up fs to given place", with the former resulting in a descriptor and the latter being mount2(Attach, dir_fd, fs_fd); Kernel side of autofs might receive the file descriptor in question and do the rest itself... -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
