Messages in this thread | | | Date | Mon, 10 Oct 2022 10:22:34 +0200 | From | Michal Koutný <> | Subject | Re: [PATCH v2] cgroup: Reorganize css_set_lock and kernfs path processing |
| |
On Wed, Oct 05, 2022 at 06:47:31AM -1000, Tejun Heo <tj@kernel.org> wrote: > Hmm... isn't current's root cgrp guaranteed to be alive?
True on the default hierarchy. v1 hierarchies (singular ones with root cgroup only) can be unmounted.
> How would cgroup_get_live() fail?
kill_sb is not synchronized via css_set_lock.
> Also, shouldn't cgroup_get() enough for path walking?
If ref count dropped to zero, release callback (css_release_work_fn) would be queued, cgroup_get would increase the refcount but it won't cancel this.
Note these were concerns with the first version of the patch that also touched cgroup_show_path() (that processes v1 hierarchies too). With the reduction I avoided this.
Strictly speaking, even css_set_lock is unnecessary around current_cgns_cgroup_from_root() when called with cgrp_dfl_root as the cset->cgrp_links is not traversed at all.
> If you really wanna do it this way, can you please add a detailed comment > here why this is safe? But I'd prefer just doing a strightforward ref > inc/dec around it.
I see the the extraction under css_set_lock without inc/dec turns out confusing. Let me expand the idea above and avoid css_set_lock completely (another message).
Michal
| |