From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751258AbbCTCrp (ORCPT <rfc822;w@1wt.eu>);
	Thu, 19 Mar 2015 22:47:45 -0400
Received: from zeniv.linux.org.uk ([195.92.253.2]:57312 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750734AbbCTCro (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 19 Mar 2015 22:47:44 -0400
Date: Fri, 20 Mar 2015 02:47:38 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Ian Kent <raven@themaw.net>,
        Kernel Mailing List <linux-kernel@vger.kernel.org>,
        David Howells <dhowells@redhat.com>,
        Oleg Nesterov <onestero@redhat.com>,
        Trond Myklebust <trond.myklebust@primarydata.com>,
        "J. Bruce Fields" <bfields@fieldses.org>,
        Benjamin Coddington <bcodding@redhat.com>,
        Jeff Layton <jeff.layton@primarydata.com>
Subject: Re: [RFC PATCH v4 03/12] vfs - move mnt_namespace definition to
 linux/mount.h
Message-ID: <20150320024738.GU29656@ZenIV.linux.org.uk>
References: <20150317022308.24592.35785.stgit@pluto.fritz.box>
 <20150317024509.24592.88118.stgit@pluto.fritz.box>
 <20150319194711.GR29656@ZenIV.linux.org.uk>
 <1426813025.2724.2.camel@pluto.fritz.box>
 <87d244fp2a.fsf@x220.int.ebiederm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87d244fp2a.fsf@x220.int.ebiederm.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Mar 19, 2015 at 08:14:05PM -0500, Eric W. Biederman wrote:

> > Yes please, I'd be more confident if you did this than me, there's
> > already enough to worry about with the series.
> 
> Given that this patchset is a security hole waiting to happen I don't
> see why Al should bother unless there are good reasons to do this
> otherwise.

There might be, actually.  &...->mnt_ns->ns is a lot saner candidate for
a reference in nsproxy than ...->mnt_ns - *that* is the part nsproxy-related
code cares about anyway, and unlike the rest of struct mnt_namespace it
doesn't have to be opaque for everything outside of (small part of) core
VFS.  Additionally, ->mnt_ns is a bad name choice - it sounds like a field
of struct mount and, worse yet, there *is* a field of struct mount with
that name.  Confusing for no good reason and makes both harder to grep for.
And current_mnt_ns() is definitely open-coded too many times - the first
commit in that series makes sense regardless of anything else.