lkml.org 
[lkml]   [2019]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH v8 0/7] freezer for cgroup v2
    Date
    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!

    \
     
     \ /
      Last update: 2019-02-20 23:02    [W:3.974 / U:0.616 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site