On 01/15/2010 03:18 AM, Valerie Aurora wrote: > On Thu, Jan 14, 2010 at 05:43:22AM +0000, Al Viro wrote: >> On Sat, Jan 02, 2010 at 08:44:25AM +0800, Ian Kent wrote: >>> On Wed, Dec 23, 2009 at 03:36:57PM -0800, Valerie Aurora wrote: >>>> From: Jan Blunck <jblunck@xxxxxxx> >>>> >>>> This is a bugfix/replacement for commit >>>> 051d381259eb57d6074d02a6ba6e90e744f1a29f: >>>> >>>> During a path walk if an autofs trigger is mounted on a dentry, >>>> when the follow_link method is called, the nameidata struct >>>> contains the vfsmount and mountpoint dentry of the parent mount >>>> while the dentry that is passed in is the root of the autofs >>>> trigger mount. I believe it is impossible to get the vfsmount of >>>> the trigger mount, within the follow_link method, when only the >>>> parent vfsmount and the root dentry of the trigger mount are >>>> known. >>>> >>>> The solution in this commit was to replace the path embedded in the >>>> parent's nameidata with the path of the link itself in >>>> __do_follow_link(). This is a relatively harmless misuse of the >>>> field, but union mounts ran into a bug during follow_link() caused by >>>> the nameidata containing the wrong path (we count on it being what it >>>> is all other places - the path of the parent). >>>> >>>> A cleaner and easier to understand solution is to save the necessary >>>> vfsmount in the autofs superblock info when it is mounted. Then we >>>> can easily update the vfsmount in autofs4_follow_link(). >>>> >>>> Signed-off-by: Jan Blunck <jblunck@xxxxxxx> >>>> Signed-off-by: Valerie Aurora <vaurora@xxxxxxxxxx> >>> Acked-by: <raven@xxxxxxxxxx> >>> >>> Don't know how I missed such an obvious solution when I did this. >>> Thanks, Ian >> >> TBH, I don't like either variant (both the in-tree one and that). >> The reason why vfsmount does *NOT* belong in superblock, TYVM: you've >> messed the lifetime rules. You can't pin it down, or the damn thing will >> be impossible to kill. OTOH, you have no promise whatsoever that superblock >> won't outlive the initial vfsmount. You might get another vfsmount over >> the same thing and once the original one is gone... >> >> 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. Ian -- 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
