On Thu, Jan 13, 2011 at 2:53 PM, Nick Piggin <npiggin@xxxxxxxxx> wrote: > On Wed, Jan 12, 2011 at 4:48 AM, David Howells <dhowells@xxxxxxxxxx> wrote: >> Add a dentry op (d_automount) to handle automounting directories rather than >> abusing the follow_link() inode operation. The operation is keyed off a new >> inode flag (S_AUTOMOUNT). >> >> This makes it easier to add an AT_ flag to suppress terminal segment automount >> during pathwalk. It should also remove the need for the kludge code in the >> pathwalk algorithm to handle directories with follow_link() semantics. >> >> A new pathwalk subroutine, follow_automount() is added to handle mountpoints. >> It will return -EREMOTE if the S_AUTOMOUNT was set, but no d_automount() op was >> supplied, -ELOOP if we've encountered too many symlinks or mountpoints, -EISDIR >> if the walk point should be used without mounting and 0 if successful. path >> will be updated if an automount took place to point to the mounted filesystem. >> >> I've only changed __follow_mount() to handle call follow_automount(), but it >> might be necessary to change follow_mount() too. The latter is only called >> from follow_dotdot(), but any automounts on ".." should be pinned whilst we're >> using a child of it. >> >> I've also extracted the mount/don't-mount logic from autofs4 and included it >> here. It makes the mount go ahead anyway if someone calls open() or creat(), >> tries to traverse the directory, tries to chdir/chroot/etc. into the directory, >> or sticks a '/' on the end of the pathname. If they do a stat(), however, >> they'll only trigger the automount if they didn't also say O_NOFOLLOW. >> >> Signed-off-by: David Howells <dhowells@xxxxxxxxxx> >> Acked-by: Ian Kent <raven@xxxxxxxxxx> > > I would still prefer to see a .follow_mount API, and not tie in this automount > specific inode detail to what could be a more flexible dentry-only API. > > The default NULL implementation would do nothing, and follow_automount > stuff can be in fs/libfs.c to be used by filesystem, rather than fs/namei.c. Looking further in the patchset at the d_managed "thing", that's almost what I'm getting at. But I don't see why any of this stuff has to happen in fs/namei.c. Just call the function from path walk, and provide helpers in libfs or something if there is a lot of common code between autofs4 and others (and leave it autofs specifc when that is the case). Of course, that would be the obvious and naive first approach. So really my question is why did that not work? And can we make it work? Second observation when adding rcu-walk/ref-walk operations. What we've done now (which is what Linus preferred and I agree with now) is to make functions always able to accept rcu-walk mode, and have filesystems bail out as needed. Unless there are really fundamental reasons why rcu-walk won't work (eg. ->lookup, if it is required to do allocations and IO), or if it really doesn't matter (eg. a function to be called once to set up a mount, and never again). -- 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
