[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170524180106.GA85439@evv-mbp.dhcp.thefacebook.com>
Date: Wed, 24 May 2017 11:01:07 -0700
From: Shaohua Li <shli@...com>
To: Tejun Heo <tj@...nel.org>
CC: Christoph Hellwig <hch@...radead.org>,
<linux-kernel@...r.kernel.org>, <gregkh@...uxfoundation.org>,
<viro@...iv.linux.org.uk>, <Kernel-team@...com>
Subject: Re: [PATCH 5/5] kernfs: add exportfs operations
On Wed, May 24, 2017 at 01:46:04PM -0400, Tejun Heo wrote:
> Hello, Christoph.
>
> On Wed, May 24, 2017 at 10:41:38AM -0700, Christoph Hellwig wrote:
> > > But how do you map that back to the cgroup without scanning the cgroup
> > > hierarchy?
> >
> > I'm totally lost on why you would do that. So maybe you just need
> > to send the full patch so that reviewers get the full picture.
>
> Here's a simple scenario. Let's say blktrace now exposes the cgroup
> inode and generation numbers per trace. Userland tool now wants to
> show that in a human readable format but it can only map back the
> inode and generation numbers to the path by scanning the cgroup tree.
> So, the goal is having a token which is not path which uniquely
> identifies a cgroup and the ability to map that back to cgroup path.
> We can add a dedicated interface to cgroup root, for example, and
> allow querying by echoing inode and generation numbers into it but
> that's kinda clumsy.
blktrace is the target I'm working on, because we can't use pid to determine
where a bio comes from, so we show an ID. Userspace tool can use the ID to find
the cgroup path. Or an BPF program can use the ID to filter trace. Regardless
how we implement the ID, it should be something like an inode number and
generation number. And since we already had existing syscall to map between
fhandle and path, I choose the exportfs operations. I'll post a full patch set
later.
Thanks,
Shaohua
Powered by blists - more mailing lists