Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753505Ab0L3KFN (ORCPT ); Thu, 30 Dec 2010 05:05:13 -0500 Received: from mx2.parallels.com ([64.131.90.16]:49440 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753152Ab0L3KFL (ORCPT ); Thu, 30 Dec 2010 05:05:11 -0500 Message-ID: <4D1C5953.6020200@parallels.com> Date: Thu, 30 Dec 2010 04:05:07 -0600 From: Rob Landley User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Kirill A. Shutemov" CC: Rob Landley , Trond Myklebust , "J. Bruce Fields" , Neil Brown , Pavel Emelyanov , , "David S. Miller" , , Subject: Re: [PATCH v2 00/12] make rpc_pipefs be mountable multiple time References: <1293628470-28386-1-git-send-email-kas@openvz.org> <20101230085139.GA29697@shutemov.name> <4D1C4C7C.6050606@parallels.com> <20101230094433.GB29697@shutemov.name> In-Reply-To: <20101230094433.GB29697@shutemov.name> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1204 Lines: 27 On 12/30/2010 03:44 AM, Kirill A. Shutemov wrote: >>> If no rpcmount mountoption, no rpc_pipefs was found at >>> '/var/lib/nfs/rpc_pipefs' and we are in init's mount namespace, we use >>> init_rpc_pipefs. >> >> It's the "we are in init's mount namespace" that I was wondering about. >> >> So if I naievely chroot, nfs mount stops working the way it did before I >> chrooted unless I do an extra setup step? > > No. It will work as before since you are still in init's mount namespace. > Creating new mount namespace changes rules. Ah, CLONE_NEWNS and then you need /var/lib/nfs/rpc_pipefs. Got it. I'm kind of surprised that the kernel cares about a specific path under /var/lib. (Seems like policy in the kernel somehow.) Can't it just check the current process's mount list to see if an instance of rpc_pipefs is mounted in the current namespace the way lxc looks for cgroups? Or are there potential performance/scalability issues with that? Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/