13 Nov, 2008

2 commits

  • With this change, control file 'freezer.state' doesn't exist in root
    cgroup, making root cgroup unfreezable.

    I think it's reasonable to disallow freeze tasks in the root cgroup. And
    then we can avoid fork overhead when freezer subsystem is compiled but not
    used.

    Also make writing invalid value to freezer.state returns EINVAL rather
    than EIO. This is more consistent with other cgroup subsystem.

    Signed-off-by: Li Zefan
    Acked-by: Paul Menage
    Cc: Cedric Le Goater
    Cc: Paul Menage
    Cc: Matt Helsley
    Cc: "Serge E. Hallyn"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Li Zefan
     
  • In theory the task can be moved to another cgroup and the freezer will be
    freed right after task_lock is dropped, so the lock results in zero
    protection.

    But in the case of freezer_fork() no lock is needed, since the task is not
    in tasklist yet so it won't be moved to another cgroup, so task->cgroups
    won't be changed or invalidated.

    Signed-off-by: Li Zefan
    Cc: Matt Helsley
    Cc: Cedric Le Goater
    Cc: "Serge E. Hallyn"
    Cc: Paul Menage
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Li Zefan
     

31 Oct, 2008

4 commits


20 Oct, 2008

4 commits

  • check_if_frozen() sounds like it should return something when in fact it's
    just updating the freezer state.

    Signed-off-by: Matt Helsley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matt Helsley
     
  • Rename cgroup freezer states to be less generic to avoid any name
    collisions while also better describing what each state is.

    Signed-off-by: Matt Helsley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matt Helsley
     
  • Don't let frozen tasks or cgroups change. This means frozen tasks can't
    leave their current cgroup for another cgroup. It also means that tasks
    cannot be added to or removed from a cgroup in the FROZEN state. We
    enforce these rules by checking for frozen tasks and cgroups in the
    can_attach() function.

    Signed-off-by: Matt Helsley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matt Helsley
     
  • This patch implements a new freezer subsystem in the control groups
    framework. It provides a way to stop and resume execution of all tasks in
    a cgroup by writing in the cgroup filesystem.

    The freezer subsystem in the container filesystem defines a file named
    freezer.state. Writing "FROZEN" to the state file will freeze all tasks
    in the cgroup. Subsequently writing "RUNNING" will unfreeze the tasks in
    the cgroup. Reading will return the current state.

    * Examples of usage :

    # mkdir /containers/freezer
    # mount -t cgroup -ofreezer freezer /containers
    # mkdir /containers/0
    # echo $some_pid > /containers/0/tasks

    to get status of the freezer subsystem :

    # cat /containers/0/freezer.state
    RUNNING

    to freeze all tasks in the container :

    # echo FROZEN > /containers/0/freezer.state
    # cat /containers/0/freezer.state
    FREEZING
    # cat /containers/0/freezer.state
    FROZEN

    to unfreeze all tasks in the container :

    # echo RUNNING > /containers/0/freezer.state
    # cat /containers/0/freezer.state
    RUNNING

    This is the basic mechanism which should do the right thing for user space
    task in a simple scenario.

    It's important to note that freezing can be incomplete. In that case we
    return EBUSY. This means that some tasks in the cgroup are busy doing
    something that prevents us from completely freezing the cgroup at this
    time. After EBUSY, the cgroup will remain partially frozen -- reflected
    by freezer.state reporting "FREEZING" when read. The state will remain
    "FREEZING" until one of these things happens:

    1) Userspace cancels the freezing operation by writing "RUNNING" to
    the freezer.state file
    2) Userspace retries the freezing operation by writing "FROZEN" to
    the freezer.state file (writing "FREEZING" is not legal
    and returns EIO)
    3) The tasks that blocked the cgroup from entering the "FROZEN"
    state disappear from the cgroup's set of tasks.

    [akpm@linux-foundation.org: coding-style fixes]
    [akpm@linux-foundation.org: export thaw_process]
    Signed-off-by: Cedric Le Goater
    Signed-off-by: Matt Helsley
    Acked-by: Serge E. Hallyn
    Tested-by: Matt Helsley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matt Helsley