Re: [Bug Report] EBUSY for cgroup rmdir after cgroup.procs empty

[Tejun Heo <tj@kernel.org>]

Hello,

On Tue, Oct 10, 2023 at 10:14:26AM -0700, T.J. Mercier wrote:
> > BTW is there any fundamental reason the apps cannot use the
> > notifications via cgroup.events as recommended by Tejun?
> >
> This would require that we read both cgroup.procs and cgroup.events,
> since we'd still want to know which processes to signal. I assumed
> this would increase lock contention but there's no synchronization on
> cgroup_is_populated so it looks like not. I had already identified
> this as a workaround, but I'd prefer to depend on just one file to do
> everything.

I don't think we can guarantee that. There's a reason why we have
[!]populated events. Maybe we can find this particular situation better but
there isn't going to be a guarantee that a cgroup is removable if its
cgroup.procs file is seen empty.

Note that cgroup.events file is pollable. You can just poll the file and
then respond to them. I don't understand the part of having to read
cgroup.procs, which btw is an a lot more expensive operation. You said
"which processes to signal". If this is to kill all processes in the cgroup,
you can use cgroup.kill which sends signal atomically to all member tasks.

It feels like the use case is just trying to do things in an unsupported way
when there's no actual benefit to doing so. Is there something preventing
you guys from doing how it's supposed to be used?

Thanks.

-- 
tejun