On Mon, 05 Sep 2011 18:06:26 +0200 Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > From: Miklos Szeredi <mszeredi@xxxxxxx> > > Prior to 2.6.38 automount would not trigger on either stat(2) or > lstat(2) on the automount point. > > After 2.6.38, with the introduction of the ->d_automount() > infrastructure, stat(2) and others would start triggering automount > while lstat(2), etc. still would not. This is a regression and a > userspace ABI change. > > Problem originally reported here: > > http://thread.gmane.org/gmane.linux.kernel.autofs/6098 > > It appears that there was an attempt at fixing various userspace tools > to not trigger the automount. But since the stat system call is > rather common it is impossible to "fix" all userspace. > > This patch reverts the original behavior, which is to not trigger on > stat(2) and other symlink following syscalls. > > Reported-by: Leonardo Chiquitto <leonardo.lists@xxxxxxxxx> > Signed-off-by: Miklos Szeredi <mszeredi@xxxxxxx> > CC: David Howells <dhowells@xxxxxxxxxx> > CC: Ian Kent <raven@xxxxxxxxxx> > CC: stable@xxxxxxxxxx > --- > fs/namei.c | 33 +++++++++++++++------------------ > 1 file changed, 15 insertions(+), 18 deletions(-) > This patch is causing a regression with NFSv4. When I mount up a filesystem, and do any activity on it, a new automount gets triggered on top of the original mountpoint. The first mount ends up getting the fsid of the pseudo root (fsid=0), rather than the correct one for the fs. Once it traverses into the actual filesystem the fsid's look different and d_automount gets triggered. I think the problem is that nfs_follow_remote_path() uses LOOKUP_FOLLOW, and with the above patch this is now ignored. Let me know if you need details on how to reproduce this. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
