Re: [RFC PATCH] cgroup: add cgroup.signal

[Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

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