From: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Christian Brauner
<christian.brauner-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>
Cc: "Michal Koutný" <mkoutny-IBi9RG/b67k@public.gmane.org>,
"Roman Gushchin" <guro-b10kYP2dOMg@public.gmane.org>,
"Christian Brauner"
<brauner-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
"Shakeel Butt" <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
"Zefan Li" <lizefan.x-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org>,
"Johannes Weiner"
<hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC PATCH] cgroup: add cgroup.signal
Date: Wed, 28 Apr 2021 12:04:28 -0400 [thread overview]
Message-ID: <YImHjGGuIt0ebL0G@slm.duckdns.org> (raw)
In-Reply-To: <20210428143746.p6tjwv6ywgpixnjy@wittgenstein>
Hello,
On Wed, Apr 28, 2021 at 04:37:46PM +0200, Christian Brauner wrote:
> > 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.
>
> Ok, so we make write to cgroup.kill in threaded cgroups EOPNOTSUPP which
> is equivalent what a read on cgroup.procs would yield.
Sounds good to me.
> Tejun, Roman, Michal, I've been thinking a bit about the escaping
> children during fork() when killing a cgroup and I would like to propose
> we simply take the write-side of threadgroup_rwsem during cgroup.kill.
>
> This would give us robust protection against escaping children during
> fork() since fork()ing takes the read-side already in cgroup_can_fork().
> And cgroup.kill should be sufficiently rare that this isn't an
> additional burden.
>
> Other ways seems more fragile where the child can potentially escape
> being killed. The most obvious case is when CLONE_INTO_CGROUP is not
> used. If a cgroup.kill is initiated after cgroup_can_fork() and after
> the parent's fatal_signal_pending() check we will wait for the parent to
> release the siglock in cgroup_kill(). Once it does we deliver the fatal
> signal to the parent. But if we haven't passed cgroup_post_fork() fast
> enough the child can be placed into that cgroup right after the kill.
> That's not super bad per se since the child isn't technically visible in
> the target cgroup anyway but it feels a bit cleaner if it would die
> right away. We could minimize the window by raising a flag say CGRP_KILL
> say:
So, yeah, I wouldn't worry about the case where migration is competing
against killing. The order of operations simply isn't defined and any
outcome is fine. As for the specific synchronization method to use, my gut
feeling is whatever which aligns better with the freezer implementation but
I don't have strong feelings otherwise. Roman, what do you think?
Thanks.
--
tejun
next prev parent reply other threads:[~2021-04-28 16:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-23 17:13 [RFC PATCH] cgroup: add cgroup.signal Christian Brauner
[not found] ` <20210423171351.3614430-1-brauner-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2021-04-23 19:01 ` Roman Gushchin
[not found] ` <YIMZkjzNFypjZao9-cx5fftMpWqeCjSd+JxjunQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
2021-04-26 14:42 ` Michal Koutný
2021-04-26 15:15 ` Christian Brauner
2021-04-26 19:02 ` Michal Koutný
2021-04-26 14:42 ` Michal Koutný
2021-04-26 15:29 ` Christian Brauner
2021-04-26 16:08 ` Shakeel Butt
[not found] ` <CALvZod5=eLQMdVXxuhj9ia=PkoRvT5oBxeqZAVtQpSukZ=tCxA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2021-04-26 16:24 ` Christian Brauner
2021-04-26 19:03 ` Michal Koutný
2021-04-27 9:36 ` Christian Brauner
2021-04-27 14:29 ` Tejun Heo
[not found] ` <YIgfrP5J3aXHfM1i-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2021-04-28 14:37 ` Christian Brauner
2021-04-28 16:04 ` Tejun Heo [this message]
[not found] ` <YImHjGGuIt0ebL0G-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2021-04-28 18:12 ` Roman Gushchin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YImHjGGuIt0ebL0G@slm.duckdns.org \
--to=tj-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
--cc=brauner-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=christian.brauner-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org \
--cc=guro-b10kYP2dOMg@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=lizefan.x-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org \
--cc=mkoutny-IBi9RG/b67k@public.gmane.org \
--cc=shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox