Re: [PATCH] autofs - fix fix symlinks arent checked for expiry
From: Ian Kent
Date: Thu Dec 26 2013 - 20:10:02 EST
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?
>
> > --- 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?
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.
>
> static void *autofs4_follow_link(struct dentry *dentry, struct nameidata *nd)
> {
> nd_set_link(nd, dentry->d_inode->i_private);
> return NULL;
> }
>
Ian
--
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/