All of lore.kernel.org
 help / color / mirror / Atom feed
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.