On Tue, Oct 17, 2023 at 10:04 PM Michal Koutný <mkoutny@xxxxxxxx> wrote: > > Hi. > > I'd like this proc_cgroup_show de-contention. > (Provided the previous patch and this one can be worked out somehow.) Thanks > > On Tue, Oct 17, 2023 at 12:45:39PM +0000, Yafang Shao <laoar.shao@xxxxxxxxx> wrote: > > They can ran successfully after implementing this change, with no RCU > > warnings in dmesg. It's worth noting that this change can also catch > > deleted cgroups, as demonstrated by running the following task at the > > same time: > > Can those be other than v1 root cgroups? A suffix "(unmounted)" may be > more informative then. They can only be a v1 root cgroups. will use the "(unmounted)" instead. Thanks for your suggestion. > > (Non-zombie tasks prevent their cgroup removal, zombie tasks won't have > any non-trivial path rendered.) > > > > @@ -6256,7 +6256,7 @@ int proc_cgroup_show(struct seq_file *m, struct pid_namespace *ns, > > if (!buf) > > goto out; > > > > - cgroup_lock(); > > + rcu_read_lock(); > > What about the cgroup_path_ns_locked() that prints the path? I believe we can further enhance cgroup_path_ns() by replacing the cgroup_lock with rcu_read_lock. However, we need to explicitly address the NULL root case, which may necessitate some refactoring. Perhaps this can be improved in a separate patchset? > > (I argue above that no non-trivial path is rendered but I'm not sure > whether rcu_read_lock() is sufficient sync wrt cgroup rmdir.) > -- Regards Yafang
