From: ebiederm@xmission.com (Eric W. Biederman)
To: Dick Streefland <dick@streefland.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: autofs multi-map regression
Date: Fri, 16 Jun 2017 15:57:58 -0500 [thread overview]
Message-ID: <87r2yjr6p5.fsf@xmission.com> (raw)
In-Reply-To: <20170616101440.GA1480@neos> (Dick Streefland's message of "Fri, 16 Jun 2017 12:14:41 +0200")
Dick Streefland <dick@streefland.net> writes:
> After a recent upgrade of a Ubuntu xenial machine, a particular
> autofs multi-map mount setup stopped working. A simplified example is:
>
> ::::::::::::::
> auto.master
> ::::::::::::::
> /net /etc/auto.net
> ::::::::::::::
> auto.net
> ::::::::::::::
> localhost / :/ /loc :/loc
>
> Accessing /net/localhost/loc should trigger two nested bind mounts on
> /net/localhost and /net/localhost/loc, but with the new kernel, it fails
> with ELOOP:
>
> $ ls /net/localhost/loc
> ls: cannot open directory '/net/localhost/loc': Too many levels of symbolic links
>
> The problem is related to the upgrade of the Ubuntu xenial kernel from
> 4.4.0-38.57 to 4.4.0-78.99. I bisected the regression to commit
> 731ac92843877f3633325203abc942193c1e9001, which is a Ubuntu backport
> of this upstream kernel commit:
>
> commit 1064f874abc0d05eeed8993815f584d847b72486
> Author: Eric W. Biederman <ebiederm@xmission.com>
> Date: Fri Jan 20 18:28:35 2017 +1300
>
> mnt: Tuck mounts under others instead of creating shadow/side mounts.
I don't believe this is a kernel change.
I dug up an old VM and I was able to reproduce this issue simply
by installing autofs, and your auto.master and auto.net files.
# uname -a
Linux ubuntu-16 4.4.0-24-generic #43-Ubuntu SMP Wed Jun 8 19:27:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
# ls /net/
localhost
# ls /net/localhost/loc
ls: cannot open directory '/net/localhost/loc': Too many levels of symbolic links
# ls /loc
ls: cannot open directory '/loc/': Too many levels of symbolic links
I suspect there is configuration somewhere in your autofs
configuration. I don't speak autofs well enough to debug the issue at
this point. But I can conclusively say it was not the kernel commit you
pointed at, as I see the issue you are reporting and I don't have that
commit in the kernel under test.
Eric
next prev parent reply other threads:[~2017-06-16 21:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-16 10:14 autofs multi-map regression Dick Streefland
2017-06-16 17:03 ` Eric W. Biederman
2017-06-16 20:39 ` Dick Streefland
2017-06-16 21:08 ` Eric W. Biederman
2017-06-16 20:57 ` Eric W. Biederman [this message]
2017-06-16 21:41 ` Dick Streefland
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=87r2yjr6p5.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=dick@streefland.net \
--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.