On Wed, Feb 20, 2019 at 03:37:48PM +0100, Oleg Nesterov wrote: > On 02/19, Roman Gushchin wrote: > > > > It provides similar functionality as v1 freezer, but the interface > > conforms to the cgroup v2 interface design principles, and it > > provides a better user experience: tasks can be killed, ptrace works, > > I tried to not argue with intent, but to be honest I am more and more > sceptical... Lets forget about ptrace for the moment. > > Once again, why do we want a killable freezer? > > If a user wants to kill a frozen task from CGRP_FROZEN cgroup he can simply > > 1. send SIGKILL to that task > > 2. migrate it to the root cgroup. > > why this doesn't / can't work? It does work, but it doesn't look as a nice interface to take into the cgroup v2 world. It just not clear, why killing a frozen task requires some cgroup-level operations? It doesn't add anything except some additional complexity to the userspace. Generally speaking, any process hanging in D-state for a long time isn't the nicest object from the userspace's point of view. Exactly as a SIGSTOPped process can be killed without sending SIGCONT, why a frozen task would require some additional operations? And I'm not talking about the case, when the process which is sending SIGKILL has no write access to cgroupfs. > Why I am starting to argue... The ability to kill a frozen task complicates > the code, and since cgroup_enter_stopped() (in this version at least) doesn't > properly interacts with freezable_schedule() leads to other problems. > > From 7/7: > > + cgroup.freeze > + A read-write single value file which exists on non-root cgroups. > + Allowed values are "0" and "1". The default is "0". > + > + Writing "1" to the file causes freezing of the cgroup and all > + descendant cgroups. This means that all belonging processes will > + be stopped and will not run until the cgroup will be explicitly > + unfrozen. Freezing of the cgroup may take some time; > ^^^^^^^^^^^^^^^^^^ > it may take infinite time. > > Just suppose that a task does vfork() and this races with cgroup_do_freeze(true). > If the new child notices JOBCTL_TRAP_FREEZE before exit/exec the cgroup will be > never frozen. Hm, why? cgroup_update_frozen() called from cgroup_post_fork() should bring the cgroup into the frozen state. If it's not true (I'm missing some race here), it's a bug, but I don't see why it's not possible in general. > > If I read the current kernel/cgroup/freezer.c correctly, CGROUP_FREEZING should > "always" work (unless a task hangs in D state) and to me this looks more important > than kill/ptrace support... Again, I don't see a case, when cgroup v1 freezer will work and the proposed v2 freezer won't work in general. > > > there is no separate controller, which has to be enabled, etc. > > agreed, this is nice. Thanks!
