Re: autofs linux 3.8.13 and "Too many levels of symbolic links"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2014-01-31 at 11:31 +0800, Ian Kent wrote:
> On Wed, 2014-01-29 at 17:02 +0100, Donald Buczek wrote:
> > Hello,
> > 
> > we are trying to switch from amd to autofs. After successfully testing 
> > and rolling it out to the first several machines, from time to time we 
> > get directories stuck with "Too many levels of symbolic links" on a path 
> > which should be automounted via an indirect map.
> > 
> > linux 3.8.13
> > autofs 5.0.8
> > 
> > As an example, here is data from a system where the path /scratch/tmp is 
> > stuck:
> > 
> > http://www.molgen.mpg.de/~buczek/autofs-demo/
> > 
> >    auto.master    # master map
> >    auto.scratch    # indirect map for /scratch
> >    autofs            # from /etc/defaults
> >    typescript       # shows the problem and a bit of gdb dump of kernel 
> > structures
> >    typescript.l     # same with line numbers for reference
> >    gdb-macros     # macros used in the gdb session
> > 
> >  From typescript.l , line 122ff it is clear, that /scratch/tmp is not 
> > currently mounted. On the other hand, the gdb session finds the dentry 
> > of /scratch/tmp which has d_flags 0x70080 (line 99,120). This is 
> > DCACHE_MANAGE_TRANSIT+DCACHE_NEED_AUTOMOUNT+DCACHE_MOUNTED+DCACHE_RCUACCESS 
> > with DCACHE_MOUNTED indicating that there should be something mounted 
> > there(?). I think, this state is faulty and necessarily leads to ELOOP 
> > during path walk. Probably the situation is known by the gurus here?
> 
> Yes, I can see how DCACHE_MOUNTED being set would lead to ELOOP in this
> case. But, having been there before too, I couldn't see any way the
> DCACHE_MOUNTED would not be cleared on umount. Also, DCACHE_MOUNTED is
> only changed within the VFS and isn't changed very often. It can't see
> how a code path that should lead to one of those changes doesn't go
> there.
> 
> I'll have another look .....

Then the question becomes ....

Can a dentry be a mount point for more than one mount ....
Obviously not you say ... but what about clone(2) with CLONE_NEWNS?

If you still have that kernel you used to get the info above could you
check the mount (ie. struct mount not struct vfsmount) structures to see
if there is one with its mnt_mountpoint set to the dentry in question?

Ian


--
To unsubscribe from this list: send the line "unsubscribe autofs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux Ext4]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux