Hello,
On Tue, Apr 27, 2021 at 11:36:06AM +0200, Christian Brauner wrote:
> I thought about this optimization but (see below) given that it should
> work with threaded cgroups we can't only walk thread-group leaders,
> afaiu.
CSS_TASK_ITER_PROCS|CSS_TASK_ITER_THREADED iterates all thread group leaders
in the threaded domain and is used to implement cgroup.procs. This should
work, right?
> > > @@ -4846,6 +4916,11 @@ static struct cftype cgroup_base_files[] = {
> > > + {
> > > + .name = "cgroup.signal",
> > > + .flags = CFTYPE_NOT_ON_ROOT,
> > > + .write = cgroup_signal_write,
> >
> > I think this shouldn't be visible in threaded cgroups (or return an
> > error when attempting to kill those).
>
> I've been wondering about this too but then decided to follow freezer in
> that regard. I think it should also be fine because a kill to a thread
> will cause the whole thread-group to be taken down which arguably is the
> semantics we want anyway.
I'd align it with cgroup.procs. Killing is a process-level operation (unlike
arbitrary signal delivery which I think is another reason to confine this to
killing) and threaded cgroups should be invisible to process-level
operations.
Thanks.
--
tejun
