From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756960AbbLAV65 (ORCPT ); Tue, 1 Dec 2015 16:58:57 -0500 Received: from h2.hallyn.com ([78.46.35.8]:47540 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755737AbbLAV6z (ORCPT ); Tue, 1 Dec 2015 16:58:55 -0500 Date: Tue, 1 Dec 2015 15:58:53 -0600 From: "Serge E. Hallyn" To: Tejun Heo Cc: "Serge E. Hallyn" , serge@hallyn.com, linux-kernel@vger.kernel.org, adityakali@google.com, linux-api@vger.kernel.org, containers@lists.linux-foundation.org, cgroups@vger.kernel.org, lxc-devel@lists.linuxcontainers.org, akpm@linux-foundation.org, ebiederm@xmission.com Subject: Re: [PATCH 7/8] cgroup: mount cgroupns-root when inside non-init cgroupns Message-ID: <20151201215853.GA9153@mail.hallyn.com> References: <1447703505-29672-1-git-send-email-serge@hallyn.com> <1447703505-29672-8-git-send-email-serge@hallyn.com> <20151124171610.GS17033@mtj.duckdns.org> <20151127051745.GA24521@mail.hallyn.com> <20151130150938.GF3535@mtj.duckdns.org> <20151201040704.GA31067@mail.hallyn.com> <20151201164649.GD12922@mtj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151201164649.GD12922@mtj.duckdns.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 01, 2015 at 11:46:49AM -0500, Tejun Heo wrote: > Hey, Serge. > > On Mon, Nov 30, 2015 at 10:07:04PM -0600, Serge E. Hallyn wrote: > > So actually the way the code is now, the first mount cannot > > be done from a non-init user namespace; and kernfs_obtain_root() > > is only called from non-init user namespace. So can we assume > > that the root dentry will be instantiated? (or can it get > > evicted?) > > > > If we can assume that then most of that fn can go away. > > The v2 hierarchy is always mounted and non-init ns shouldn't be able > to create new v1 hierarchies, so the root dentry should always be > there. I mispoke before though - it's not the hierarchy's root dentry, but rather a dentry for a descendent cgroup which will become the root dentry for the new superblock. We do know that there must be a css_set with a cgroup. I'm still trying to track down whether that cgrou's inode's dentry can ever be flushed. I would think not but am not sure. From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Serge E. Hallyn" Subject: Re: [PATCH 7/8] cgroup: mount cgroupns-root when inside non-init cgroupns Date: Tue, 1 Dec 2015 15:58:53 -0600 Message-ID: <20151201215853.GA9153@mail.hallyn.com> References: <1447703505-29672-1-git-send-email-serge@hallyn.com> <1447703505-29672-8-git-send-email-serge@hallyn.com> <20151124171610.GS17033@mtj.duckdns.org> <20151127051745.GA24521@mail.hallyn.com> <20151130150938.GF3535@mtj.duckdns.org> <20151201040704.GA31067@mail.hallyn.com> <20151201164649.GD12922@mtj.duckdns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20151201164649.GD12922-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Tejun Heo Cc: "Serge E. Hallyn" , serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, adityakali-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, lxc-devel-cunTk1MwBs9qMoObBWhMNEqPaTDuhLve2LY78lusg7I@public.gmane.org, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org List-Id: linux-api@vger.kernel.org On Tue, Dec 01, 2015 at 11:46:49AM -0500, Tejun Heo wrote: > Hey, Serge. > > On Mon, Nov 30, 2015 at 10:07:04PM -0600, Serge E. Hallyn wrote: > > So actually the way the code is now, the first mount cannot > > be done from a non-init user namespace; and kernfs_obtain_root() > > is only called from non-init user namespace. So can we assume > > that the root dentry will be instantiated? (or can it get > > evicted?) > > > > If we can assume that then most of that fn can go away. > > The v2 hierarchy is always mounted and non-init ns shouldn't be able > to create new v1 hierarchies, so the root dentry should always be > there. I mispoke before though - it's not the hierarchy's root dentry, but rather a dentry for a descendent cgroup which will become the root dentry for the new superblock. We do know that there must be a css_set with a cgroup. I'm still trying to track down whether that cgrou's inode's dentry can ever be flushed. I would think not but am not sure.