[AFS, CIFS and NFS maintainers added to Cc] On Fri, Jan 15, 2010 at 02:05:24PM +0800, Ian Kent wrote: > >> So this is simply broken. > > > > Ian, you're the expert - any ideas? What are the constraints here? > > It looks to me like the struct path coming to __do_follow_link() has > what I need. A potentially big change, but using the struct path instead > of the dentry in the inode op follow_link() call would get me what I > need in my follow_link() call without having to store anything. Yuck. If we go for change of ->follow_link() prototype, we might as well DTRT and split the damn thing instead of trying to overload an unsuitable method. Let's see what's really going on there. AFAICT, we have several, er, oddities in the area: * abuse of mnt_devname by nfs; do we ever want it to differ (for nfs automounting purposes) for different vfsmounts over the same superblock? * inconsistent behaviour when something had managed to mount first. Some expect the possibility of -EBUSY, some do not. * WTF is CIFS doing setting MNT_SHRINKABLE on *parent* vfsmount? Blindly, not even bothering to cooperate with mnt_make_readonly() and its ilk. Most of all, _why_? It's child that should be marked so, not the parent... * speaking of which, what should happen to other vfsmount flags? NFS seems to want them all inherited and MNT_SHRINKABLE set, which is reasonable enough; CIFS sets MNT_SHRINKABLE on parent and inherits everything; AFS can't be arsed and just sets MNT_SHRINKABLE, all flags on parent be damned. * what's going on with use of intent flags in case of autofs4? Other than that, it'd seem that we would be better off if we treated these guys as "if we try to follow mountpoint and that sucker turns out to be the end of the road, do something fs-specific and either try to go further or see if we could attach the mountpoint given to us here". Which might be better done in VFS, with fs method returning vfsmount, NULL or ERR_PTR. And yes, it'd mean rework of vfsmount expiry interface; we'd need to put the vfsmount on expiry list before attaching it anywhere. Not a big deal, that... Comments? It's obviously not a solution yet and this direction might very well turn out to be unfeasible, but let's at least see where that might lead. There are, after all, 4 users of that stuff. Should be enough to figure out what we really need and come up with a sane design... -- 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
