From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754064AbdEXRjo (ORCPT ); Wed, 24 May 2017 13:39:44 -0400 Received: from mail-yw0-f194.google.com ([209.85.161.194]:35163 "EHLO mail-yw0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753880AbdEXRjm (ORCPT ); Wed, 24 May 2017 13:39:42 -0400 Date: Wed, 24 May 2017 13:39:39 -0400 From: Tejun Heo To: Christoph Hellwig Cc: Shaohua Li , linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org, viro@zeniv.linux.org.uk, Kernel-team@fb.com Subject: Re: [PATCH 5/5] kernfs: add exportfs operations Message-ID: <20170524173939.GJ24798@htj.duckdns.org> References: <3d3a0860317afa0fb722c1a6df58e04593fc700a.1495490800.git.shli@fb.com> <20170523074019.GC29525@infradead.org> <20170523185711.GB13222@htj.duckdns.org> <20170524173822.GB13151@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170524173822.GB13151@infradead.org> User-Agent: Mutt/1.8.2 (2017-04-18) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Christoph. On Wed, May 24, 2017 at 10:38:22AM -0700, Christoph Hellwig wrote: > On Tue, May 23, 2017 at 02:57:11PM -0400, Tejun Heo wrote: > > > > Yeah, this is one of the repeatedly requested features - a cgroup id > > which can be looked up in a scalable way. We probably should have > > added this earlier too as we already have places where we're passing > > in full cgroup path into the kernel (ipt_cgroup match). > > I still have no idea how this ties into export ops. Currently I don't > see any tracing code using export operations, so maybe a big part of > the series is missing/ Oh yeah, it's not adding any users yet. > > IIUC, Shaohua is adding it so that block tracing can be made aware of > > cgroups but something like this is necessary whenever we try to refer > > to a cgroup in a race-free / scalable way. > > You can already get i_ino using statx, and i_generation using > FS_IOC_GETVERSION, so I'm a little lost on why you need the full > exportfs infrastructure. But how do you map that back to the cgroup without scanning the cgroup hierarchy? Thanks. -- tejun