Re: [PATCH 1/7] autofs4: Save autofs trigger's vfsmount in super block info

[Valerie Aurora <vaurora@redhat.com>]

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@suse.de>
> > > 
> > > 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@suse.de>
> > > Signed-off-by: Valerie Aurora <vaurora@redhat.com>
> > Acked-by: <raven@themaw.net>
> > 
> > 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?

-VAL