On Mon, 2011-03-28 at 19:53 -0300, Leonardo Chiquitto wrote:
> Hello,
>
> After the update to 2.6.38, I noticed that AutoFS started to mount volumes
> at times it normally wouldn't. More specifically, "ls -la" inside an AutoFS
> mount point will trigger the mount of all available maps.
>
> This can be reproduced with a simple indirect mount setup:
>
> # cat /etc/auto.master
> /data /etc/auto.data
>
> # cat /etc/auto.data
> isos -fstype=nfs4,ro,rsize=8192,wsize=8192,intr,nolock,nosuid libre:/isos
>
> # egrep '(autofs|nfs4)' /proc/mounts
> /etc/auto.data /data autofs
> rw,relatime,fd=7,pgrp=4300,timeout=600,minproto=5,\
> maxproto=5,indirect 0 0
>
> # stat -L /data/isos > /dev/null
How about an strace of this please?
>
> # egrep '(autofs|nfs4)' /proc/mounts
> /etc/auto.data /data autofs
> rw,relatime,fd=7,pgrp=4300,timeout=600,minproto=5,\
> maxproto=5,indirect 0 0
> libre:/isos /data/isos nfs4 ro,nosuid,relatime,vers=4,(.. more mount
> options ..) 0 0
>
> Bisecting the changes between 2.6.37 and 2.6.38, I found that 2.6.38-rc1
> exhibits the new behavior already. I went as near 2.6.37 as I could and
> verified
> that commit b650c858c2 (autofs4: Merge the remaining dentry ops tables) also
> shows the new behavior. I tried to bisect the remaining ~18 commits
> but everything
> I tested/built ended up unbootable.
>
> I also tested mainline and verified that the problem is still there.
There where two significant patch series merged in 2.6.38 which were to
similar parts of the VFS. One was the vfs-scale series and the other was
the vfs-automount series. So 2.6.38 had significant autofs changes.
I think the mount storm your seeing would be due to this check not
catching lstat(2) calls, but AFAICS it should catch this case:
if (!(flags & LOOKUP_FOLLOW) &&
!(flags & (LOOKUP_CONTINUE | LOOKUP_DIRECTORY |
LOOKUP_OPEN | LOOKUP_CREATE)))
return -EISDIR;
What do you think David?
Ian
_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
