From: ebiederm@xmission.com (Eric W. Biederman)
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: <linux-kernel@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
Serge Hallyn <serge.hallyn@canonical.com>,
Aditya Kali <adityakali@google.com>,
Oleg Nesterov <oleg@redhat.com>,
Andy Lutomirski <luto@amacapital.net>,
Gao feng <gaofeng@cn.fujitsu.com>,
Al Viro <viro@ZenIV.linux.org.uk>
Subject: [GIT PULL] namespace fixes
Date: Thu, 16 Jan 2014 22:36:21 -0800 [thread overview]
Message-ID: <877g9zcdy2.fsf@xmission.com> (raw)
Linus,
Please pull the for-linus branch from the git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-linus
HEAD: 41301ae78a99ead04ea42672a1ab72c6f44cc81d vfs: Fix a regression in mounting proc
This is a set of 3 regression fixes.
This fixes /proc/mounts when using "ip netns add <netns>" to display the
actual mount point.
This fixes a regression in clone that broke lxc-attach.
This fixes a regression in the permission checks for mounting /proc that
made proc unmountable if binfmt_misc was in use. Oops.
My apologies for sending this pull request so late. Al Viro gave
interesting review comments about the d_path fix that I wanted to
address in detail before I sent this pull request. Unfortunately a
bad round of colds kept from addressing that in detail until today.
The executive summary of the review was:
Al: Is patching d_path really sufficient?
The prepend_path, d_path, d_absolute_path, and __d_path family of
functions is a really mess.
Me: Yes, patching d_path is really sufficient. Yes, the code is mess.
No it is not appropriate to rewrite all of d_path for a regression
that has existed for entirely too long already, when a two line
change will do.
Eric W. Biederman (3):
vfs: In d_path don't call d_dname on a mount point
fork: Allow CLONE_PARENT after setns(CLONE_NEWPID)
vfs: Fix a regression in mounting proc
fs/dcache.c | 7 ++++++-
fs/namespace.c | 2 +-
kernel/fork.c | 2 +-
3 files changed, 8 insertions(+), 3 deletions(-)
reply other threads:[~2014-01-17 6:36 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=877g9zcdy2.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=adityakali@google.com \
--cc=gaofeng@cn.fujitsu.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=oleg@redhat.com \
--cc=serge.hallyn@canonical.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
/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.