Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx):
> "Serge E. Hallyn" <serge.hallyn@xxxxxxxxxx> writes:
>
> >> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> >> index 671dc05..9a0d7b3 100644
> >> --- a/kernel/cgroup.c
> >> +++ b/kernel/cgroup.c
> >> @@ -1593,6 +1593,40 @@ static int rebind_subsystems(struct cgroup_root *dst_root, u16 ss_mask)
> >> return 0;
> >> }
> >>
> >> +static int cgroup_show_path(struct seq_file *sf, struct kernfs_node *kf_node,
> >> + struct kernfs_root *kf_root)
> >> +{
> >> + int len = 0, ret = 0;
> >> + char *buf = NULL;
> >> + struct cgroup_namespace *ns = current->nsproxy->cgroup_ns;
> >> + struct cgroup_root *kf_cgroot = cgroup_root_from_kf(kf_root);
> >> + struct cgroup *ns_cgroup;
> >> +
> >> + mutex_lock(&cgroup_mutex);
> >
> > Hm, I can't grab the cgroup mutex here because I already have the
> > namespace_sem. But that's required by cset_cgroup_from_root(). Can
> > I just call that under rcu_read_lock() instead? (Not without
> > changing the lockdep_assert_help()). Is there another way to get the
> > info needed here?
>
> Do we need the current cgroup namespace information at all?
>
> Could we not get the relevant cgroup namespace from the mount of
> cgroupfs?
I don't think so. That was my first inclination. But at show_path()
all we have is the vfsmunt->mnt_root. Since all cgroup namespaces
for a hierarchy share the same dentry tree and superblock, there's
no way to tell where the mount's namespace root is supposed to be.
whether we did
# enter new cgroup namespace rooted at cgroup /user.slice/user-1000.slice
mount -t cgroup -o freezer freezer /mnt
or
mount --bind /sys/fs/cgroup/freezer/user.slice/user-1000.slice /mnt
the mountinfo entry will be the same.
> In general the better path is not to have the contents of files depend on
> who is reading the file.
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
