From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1760392AbZAWIJs@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1760392AbZAWIJs (ORCPT <rfc822;w@1wt.eu>);
	Fri, 23 Jan 2009 03:09:48 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753740AbZAWIJk
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 23 Jan 2009 03:09:40 -0500
Received: from mx2.redhat.com ([66.187.237.31]:54149 "EHLO mx2.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753583AbZAWIJj (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 23 Jan 2009 03:09:39 -0500
Date: Fri, 23 Jan 2009 09:06:17 +0100
From: Oleg Nesterov <oleg@redhat.com>
To: Ian Kent <raven@themaw.net>
Cc: Andrew Morton <akpm@linux-foundation.org>, hpa@zytor.com,
       Cedric Le Goater <clg@fr.ibm.com>, Dave Hansen <haveblue@us.ibm.com>,
       Eric Biederman <ebiederm@xmission.com>,
       Pavel Emelyanov <xemul@openvz.org>, Serge Hallyn <serue@us.ibm.com>,
       Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH] autofs4: turn ->oz_pgrp into "struct pid *"
Message-ID: <20090123080617.GA4002@redhat.com>
References: <20090118073449.GA707@redhat.com> <1232686627.3011.26.camel@zeus.themaw.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1232686627.3011.26.camel@zeus.themaw.net>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 01/23, Ian Kent wrote:
>
> On Sun, 2009-01-18 at 08:34 +0100, Oleg Nesterov wrote:
> >
> > I guess autofs4_show_options()->pid_vnr() is not exactly right, but hopefully
> > not worse than the current code.
>
> But shouldn't pid_vnr(sbi->oz_pgrp) report the pid as seen in the
> namespace of the calling process? In which case the only problem would
> be listing the mount table from a subordinate namespace that cannot see
> the process which did the mount, assuming fs namespace is not linked in
> some strict way to pid namespace, this could give an odd result. What
> might happen in this case Oleg?

Yes, nothing bad can happen. pid_vnr() just returns 0 if the calling
process can't see the namespace.

But I was worried about the case when, say, we are looking at
/subnamespace_root_mount/proc/mounts.

In that case pid_vnr() will report the pid_t in the global namespace,
this differs from the case when this file is read by its own namespace
as /proc/mounts.

I do not know whether this is right or not, though.

Oleg.