All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Kent <raven@themaw.net>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	autofs mailing list <autofs@vger.kernel.org>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] autofs - fix fix symlinks arent checked for expiry
Date: Fri, 27 Dec 2013 09:09:52 +0800	[thread overview]
Message-ID: <1388106592.2446.25.camel@perseus.fritz.box> (raw)
In-Reply-To: <20131226134253.5f4b2f02a00e11b8de49770e@linux-foundation.org>

On Thu, 2013-12-26 at 13:42 -0800, Andrew Morton wrote:
> On Tue, 24 Dec 2013 17:44:59 +0800 Ian Kent <raven@themaw.net> 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


  reply	other threads:[~2013-12-27  1:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-24  9:44 [PATCH] autofs - fix fix symlinks arent checked for expiry Ian Kent
2013-12-26 21:42 ` Andrew Morton
2013-12-27  1:09   ` Ian Kent [this message]
2013-12-27  1:19     ` Andrew Morton
2013-12-27  1:55       ` Ian Kent

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1388106592.2446.25.camel@perseus.fritz.box \
    --to=raven@themaw.net \
    --cc=akpm@linux-foundation.org \
    --cc=autofs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.