Re: [RFC PATCH bpf-next v2 2/9] cgroup: Eliminate the need for cgroup_mutex in proc_cgroup_show()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux