Re: [PATCH] autofs - fix fix symlinks arent checked for expiry

[Andrew Morton]

On Fri, 27 Dec 2013 09:09:52 +0800 Ian Kent <raven@xxxxxxxxxx> wrote:

> On Thu, 2013-12-26 at 13:42 -0800, Andrew Morton wrote:
> > On Tue, 24 Dec 2013 17:44:59 +0800 Ian Kent <raven@xxxxxxxxxx> wrote:
> > 
> > > When following a symlink the last_used counter is unconditionally
> > > updated causing the expire checks from user space to prevent
> > > expiry. Opps!
> > 
> > A bit unclear.  You're saying that userspace's act of checking expiry
> > status will itself disrupt the expiry process?
> 
> If the user space expire code uses stat(2) instead of lstat(2), yes.
> It's quite possible this will be the case since it made no difference
> when not using symlinks in the autofs directory tree.
> 
> > 
> > Also, it's rather unclear what the userspace impact is here, and how
> > severe it is.  Please always carefully describe the user-visible impact
> > so that others can decide which kernel version(s) need the patch.
> 
> The impact of this is that symlinks within an an autofs directory tree
> don't cause a callback to the daemon so they can be expired (removed in
> this case).
> 
> autofs4_oz_mode() is the mechanism that's used to identify the user
> space process that's managing the automount tree. It's used in a number
> of places to prevent the process managing the tree from doing things
> like triggering mounts itself or updating the last_used counter.
> 
> It's a bit of a puzzle why it worked when I originally tested it.  But
> later when I looked at it to work out why some symlinks weren't expiring
> it was obvious.
> 
> Do you want me to re-submit this with an updated description?

Yes please.  The questions which a bugfix changelog should answer are
"should this be backported to -stable and if so, why".  It's also
helpful if it answers "if not, why not".

> > 
> > > --- a/fs/autofs4/symlink.c
> > > +++ b/fs/autofs4/symlink.c
> > > @@ -14,8 +14,9 @@
> > >  
> > >  static void *autofs4_follow_link(struct dentry *dentry, struct nameidata *nd)
> > >  {
> > > +	struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
> > >  	struct autofs_info *ino = autofs4_dentry_ino(dentry);
> > > -	if (ino)
> > > +	if (ino && !autofs4_oz_mode(sbi))
> > >  		ino->last_used = jiffies;
> > >  	nd_set_link(nd, dentry->d_inode->i_private);
> > >  	return NULL;
> > 
> > What kernel is this against?  3.13-rc5 is quite different:
> 
> That's a good question.
> Which tree should I be basing patches on?

Current Linus git is almost always the one to target.

> As it turns out it is against 3.13-rc5 which was the version the linus
> tree was at (when I pulled it) prior to mailing the patch.

Nope, autofs4_follow_link() looks like
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/autofs4/symlink.c
all the way back to 3.12.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/