Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964840AbbLBRF6 (ORCPT ); Wed, 2 Dec 2015 12:05:58 -0500 Received: from mail-yk0-f173.google.com ([209.85.160.173]:35189 "EHLO mail-yk0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933243AbbLBRFy (ORCPT ); Wed, 2 Dec 2015 12:05:54 -0500 Date: Wed, 2 Dec 2015 12:05:51 -0500 From: Tejun Heo To: "Serge E. Hallyn" Cc: 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: <20151202170551.GE19878@mtj.duckdns.org> References: <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> <20151201215853.GA9153@mail.hallyn.com> <20151202165312.GB19878@mtj.duckdns.org> <20151202165637.GA20840@mail.hallyn.com> <20151202165839.GD19878@mtj.duckdns.org> <20151202170239.GA21009@mail.hallyn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151202170239.GA21009@mail.hallyn.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1088 Lines: 27 On Wed, Dec 02, 2015 at 11:02:39AM -0600, Serge E. Hallyn wrote: > On Wed, Dec 02, 2015 at 11:58:39AM -0500, Tejun Heo wrote: > > On Wed, Dec 02, 2015 at 10:56:37AM -0600, Serge E. Hallyn wrote: > > > Can it be flushed when we know that the cgroup is being pinned by > > > a css_set? (There's either a task or a cgroup_namespace pinning it > > > or we wouldn't get here) > > > > Yeap, it can be flushed. There's no ref coming out of cgroup to the > > vfs objects. > > Ok, thanks. Still seems to me to be more work to actually walk the > path ourselves, but I'll go that route and see what it looks like :) I just dislike having two separate paths instantiating the same objects and would prefer doing it the same way userland would do if that isn't too complex but yeah it might turn out to be a lot more work. Thanks a lot! -- tejun -- 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/