freezer for cgroup v2
Subsystems (4)
v6 cover freezer for cgroup v2
This patchset implements freezer for cgroup v2.
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, there is no separate controller, which has to be enabled, etc.
Patches (1), (2) and (3) are some preparational work, patch (4) contains the implementation, patch (5) is a small cgroup kselftest fix, patch (6) covers freezer adds 6 new kselftests to cover the freezer functionality. Patch (7) adds corresponding docs.
v6->v5:
- reverted to clear TIF_SIGPENDING with additional checks before schedule(), as proposed by Oleg Nesterov
- made cgroup v2 freezer working with the system freezer (by using freezable_schedule())
- make freezer working with SIGSTOPped and PTRACEd tasks
- added tests to cover freezing a cgroup with SIGSTOPped and PTRACEd tasks
v5->v4:
- rewored cgroup state transition code (suggested by Tejun Heo)
- look at JOBCTL_TRAP_FREEZE instead of task->frozen in recalc_sigpending(), check for task->frozen and JOBCTL_TRAP_FREEZE in signal_pending_state() (suggested by Oleg Nesterov)
- some cosmetic changes in signal.c (suggested by Oleg Nesterov)
- cleaned up comments
v4->v3:
- reading nr_descendants doesn't require taking css_set_lock anymore
- fixed docs based on Mike Rapoport's feedback
- fixed double irq lock found by Dan Carpenter
v3->v2:
- dropped TASK_FROZEN for now, frozen tasks are put into TASK_INTERRUPTIBLE state; it's probably not the final version, but the API question can be discussed separately
- don't clear TIF_SIGPENDING before going to sleep, instead add task->frozen check in signal_pending_state() and recalc_sigpending()
- cgroup-level counter are now synchronized using css_set_lock, which simplified the whole code (e.g. per-cgroup works were removed)
- the amount of comments increased significantly
- many other improvements incorporating feedback from Tejun and Oleg
v2->v1:
- fixed locking aroung calling cgroup_freezer_leave()
- added docs
Roman Gushchin (7):
cgroup: rename freezer.c into legacy_freezer.c
cgroup: implement __cgroup_task_count() helper
cgroup: protect cgroup->nr_(dying_)descendants by css_set_lock
cgroup: cgroup v2 freezer
kselftests: cgroup: don't fail on cg_kill_all() error in cg_destroy()
kselftests: cgroup: add freezer controller self-tests
cgroup: document cgroup v2 freezer interface
Documentation/admin-guide/cgroup-v2.rst | 27 + include/linux/cgroup-defs.h | 39 + include/linux/cgroup.h | 46 + include/linux/sched.h | 4 + include/linux/sched/jobctl.h | 2 + kernel/cgroup/Makefile | 4 +- kernel/cgroup/cgroup-internal.h | 1 + kernel/cgroup/cgroup-v1.c | 16 - kernel/cgroup/cgroup.c | 145 +++- kernel/cgroup/freezer.c | 650 ++++++-------- kernel/cgroup/legacy_freezer.c | 481 ++++++++++ kernel/signal.c | 93 +- tools/testing/selftests/cgroup/.gitignore | 1 + tools/testing/selftests/cgroup/Makefile | 2 + tools/testing/selftests/cgroup/cgroup_util.c | 85 +- tools/testing/selftests/cgroup/cgroup_util.h | 7 + tools/testing/selftests/cgroup/test_freezer.c | 821 ++++++++++++++++++ 17 files changed, 1993 insertions(+), 431 deletions(-) create mode 100644 kernel/cgroup/legacy_freezer.c create mode 100644 tools/testing/selftests/cgroup/test_freezer.c
Signature · 1 line
2.19.2
PATCH v6 1/7 cgroup: rename freezer.c into legacy_freezer.c
Freezer.c will contain an implementation of cgroup v2 freezer, so let's rename the v1 freezer to avoid naming conflicts.
---
kernel/cgroup/Makefile | 2 +-
kernel/cgroup/{freezer.c => legacy_freezer.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename kernel/cgroup/{freezer.c => legacy_freezer.c} (100%)kernel/cgroup/Makefile +1 -1
@@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 obj-y := cgroup.o rstat.o namespace.o cgroup-v1.o -obj-$(CONFIG_CGROUP_FREEZER) += freezer.o +obj-$(CONFIG_CGROUP_FREEZER) += legacy_freezer.o obj-$(CONFIG_CGROUP_PIDS) += pids.o obj-$(CONFIG_CGROUP_RDMA) += rdma.o obj-$(CONFIG_CPUSETS) += cpuset.o
kernel/cgroup/legacy_freezer.c renamed from kernel/cgroup/freezer.c +0 -0
Signature · 1 line
2.19.2
PATCH v6 2/7 cgroup: implement __cgroup_task_count() helper
In reply to Roman GushchinThe helper is identical to the existing cgroup_task_count() except it doesn't take the css_set_lock by itself, assuming that the caller does.
Also, move cgroup_task_count() implementation into kernel/cgroup/cgroup.c, as there is nothing specific to cgroup v1.
--- kernel/cgroup/cgroup-internal.h | 1 + kernel/cgroup/cgroup-v1.c | 16 ---------------- kernel/cgroup/cgroup.c | 33 +++++++++++++++++++++++++++++++++ 3 files changed, 34 insertions(+), 16 deletions(-)
kernel/cgroup/cgroup-internal.h +1 -0
@@ -226,6 +226,7 @@ int cgroup_rmdir(struct kernfs_node *kn);int cgroup_show_path (struct seq_file *sf,struct kernfs_node *kf_node,struct kernfs_root *kf_root); +int __cgroup_task_count (const struct cgroup *cgrp);int cgroup_task_count (const struct cgroup *cgrp);/*
kernel/cgroup/cgroup-v1.c +0 -16
@@ -336,22 +336,6 @@ static struct cgroup_pidlist *cgroup_pidlist_find_create(struct cgroup *cgrp,return l; } -/** -* cgroup_task_count - count the number of tasks in a cgroup. -* @cgrp: the cgroup in question -*/ -int cgroup_task_count (const struct cgroup *cgrp) -{ -int count =0 ; -struct cgrp_cset_link *link; - -spin_lock_irq (&css_set_lock); -list_for_each_entry (link, &cgrp->cset_links, cset_link) - count += link->cset->nr_tasks; -spin_unlock_irq (&css_set_lock); -return count; -} -/* * Load a cgroup's pidarray with either procs' tgids or tasks' pids */
kernel/cgroup/cgroup.c +33 -0
@@ -563,6 +563,39 @@ static void cgroup_get_live(struct cgroup *cgrp)css_get (&cgrp->self); } +/** +* __cgroup_task_count - count the number of tasks in a cgroup. The caller +* is responsible for taking the css_set_lock. +* @cgrp: the cgroup in question +*/ +int __cgroup_task_count (const struct cgroup *cgrp) +{ +int count =0 ; +struct cgrp_cset_link *link; + +lockdep_assert_held (&css_set_lock); + +list_for_each_entry (link, &cgrp->cset_links, cset_link) + count += link->cset->nr_tasks; + +return count; +} + +/** +* cgroup_task_count - count the number of tasks in a cgroup. +* @cgrp: the cgroup in question +*/ +int cgroup_task_count (const struct cgroup *cgrp) +{ +int count; + +spin_lock_irq (&css_set_lock); + count =__cgroup_task_count (cgrp); +spin_unlock_irq (&css_set_lock); + +return count; +} +struct cgroup_subsys_state *of_css (struct kernfs_open_file *of) {struct cgroup *cgrp = of->kn->parent->priv;
Signature · 1 line
2.19.2
PATCH v6 3/7 cgroup: protect cgroup->nr_(dying_)descendants by css_set_lock
In reply to Roman GushchinThe number of descendant cgroups and the number of dying descendant cgroups are currently synchronized using the cgroup_mutex.
The number of descendant cgroups will be required by the cgroup v2 freezer, which will use it to determine if a cgroup is frozen (depending on total number of descendants and number of frozen descendants). It's not always acceptable to grab the cgroup_mutex, especially from quite hot paths (e.g. exit()).
To avoid this, let's additionally synchronize these counters using the css_set_lock.
So, it's safe to read these counters with either cgroup_mutex or css_set_lock locked, and for changing both locks should be acquired.
--- include/linux/cgroup-defs.h | 5 +++++ kernel/cgroup/cgroup.c | 6 ++++++ 2 files changed, 11 insertions(+)
include/linux/cgroup-defs.h +5 -0
@@ -348,6 +348,11 @@ struct cgroup {* Dying cgroups are cgroups which were deleted by a user, * but are still existing because someone else is holding a reference. * max_descendants is a maximum allowed number of descent cgroups. +* +* nr_descendants and nr_dying_descendants are protected +* by cgroup_mutex and css_set_lock. It's fine to read them holding +* any of cgroup_mutex and css_set_lock; for writing both locks +* should be held. */ int nr_descendants;int nr_dying_descendants;
kernel/cgroup/cgroup.c +6 -0
@@ -4723,9 +4723,11 @@ static void css_release_work_fn(struct work_struct *work)if (cgroup_on_dfl (cgrp))cgroup_rstat_flush (cgrp); +spin_lock_irq (&css_set_lock);for (tcgrp =cgroup_parent (cgrp); tcgrp; tcgrp =cgroup_parent (tcgrp)) tcgrp->nr_dying_descendants--; +spin_unlock_irq (&css_set_lock);cgroup_idr_remove (&cgrp->root->cgroup_idr, cgrp->id); cgrp->id =-1 ;
@@ -4943,12 +4945,14 @@ static struct cgroup *cgroup_create(struct cgroup *parent)if (ret) goto out_psi_free; +spin_lock_irq (&css_set_lock);for (tcgrp = cgrp; tcgrp; tcgrp =cgroup_parent (tcgrp)) { cgrp->ancestor_ids[tcgrp->level] = tcgrp->id;if (tcgrp != cgrp) tcgrp->nr_descendants++; } +spin_unlock_irq (&css_set_lock);if (notify_on_release (parent))set_bit (CGRP_NOTIFY_ON_RELEASE , &cgrp->flags);
@@ -5233,10 +5237,12 @@ static int cgroup_destroy_locked(struct cgroup *cgrp)if (parent &&cgroup_is_threaded (cgrp)) parent->nr_threaded_children--; +spin_lock_irq (&css_set_lock);for (tcgrp =cgroup_parent (cgrp); tcgrp; tcgrp =cgroup_parent (tcgrp)) { tcgrp->nr_descendants--; tcgrp->nr_dying_descendants++; } +spin_unlock_irq (&css_set_lock);cgroup1_check_for_release (parent);
Signature · 1 line
2.19.2
PATCH v6 4/7 cgroup: cgroup v2 freezer
In reply to Roman GushchinCgroup v1 implements the freezer controller, which provides an ability to stop the workload in a cgroup and temporarily free up some resources (cpu, io, network bandwidth and, potentially, memory) for some other tasks. Cgroup v2 lacks this functionality.
This patch implements freezer for cgroup v2.
Cgroup v2 freezer tries to put tasks into a state similar to jobctl stop. This means that tasks can be killed, ptraced (using PTRACE_SEIZE*), and interrupted. It is possible to attach to a frozen task, get some information (e.g. read registers) and detach. It's also possible to migrate a frozen tasks to another cgroup.
This differs cgroup v2 freezer from cgroup v1 freezer, which mostly tried to imitate the system-wide freezer. However uninterruptible sleep is fine when all tasks are going to be frozen (hibernation case), it's not the acceptable state for some subset of the system.
Cgroup v2 freezer is not supporting freezing kthreads.
If a non-root cgroup contains kthread, the cgroup still can be frozen, but the kthread will remain running, the cgroup will be shown as non-frozen, and the notification will not be delivered.
* PTRACE_ATTACH is not working because non-fatal signal delivery is blocked in frozen state.
There are some interface differences between cgroup v1 and cgroup v2 freezer too, which are required to conform the cgroup v2 interface design principles:
1) There is no separate controller, which has to be turned on:
the functionality is always available and is represented by cgroup.freeze and cgroup.events cgroup control files.
2) The desired state is defined by the cgroup.freeze control file. Any hierarchical configuration is allowed.
3) The interface is asynchronous. The actual state is available using cgroup.events control file ("frozen" field). There are no dedicated transitional states.
4) It's allowed to make any changes with the cgroup hierarchy (create new cgroups, remove old cgroups, move tasks between cgroups) no matter if some cgroups are frozen.
--- include/linux/cgroup-defs.h | 34 ++++ include/linux/cgroup.h | 46 +++++ include/linux/sched.h | 4 + include/linux/sched/jobctl.h | 2 + kernel/cgroup/Makefile | 2 +- kernel/cgroup/cgroup.c | 106 ++++++++++- kernel/cgroup/freezer.c | 329 +++++++++++++++++++++++++++++++++++ kernel/signal.c | 93 +++++++++- 8 files changed, 607 insertions(+), 9 deletions(-) create mode 100644 kernel/cgroup/freezer.c
include/linux/cgroup-defs.h +34 -0
@@ -64,6 +64,12 @@ enum {* specified at mount time and thus is implemented here. */ CGRP_CPUSET_CLONE_CHILDREN , + +/* Control group has to be frozen. */ +CGRP_FREEZE , + +/* Cgroup is frozen. */ + CGRP_FROZEN, };/* cgroup_root->flags */
@@ -316,6 +322,31 @@ struct cgroup_rstat_cpu {struct cgroup *updated_next;/* NULL iff not on the list */ }; +struct cgroup_freezer_state { +/* Should the cgroup and its descendants be frozen. */ +bool freeze; + +/* Should the cgroup actually be frozen? */ +int e_freeze; + +/* Fields below are protected by css_set_lock */ + +/* Number of frozen descendant cgroups */ +int nr_frozen_descendants; + +/* Number of tasks to freeze */ +int nr_tasks_to_freeze; + +/* Number of frozen tasks */ +int nr_frozen_tasks; + +/* +* Number of tasks, which are counted as frozen: +* SIGSTOPped, and PTRACEd. +*/ +int nr_stopped_tasks; +}; +struct cgroup {/* self css with NULL ->ss, points back to this cgroup */ struct cgroup_subsys_state self;
@@ -452,6 +483,9 @@ struct cgroup {/* If there is block congestion on this cgroup. */ atomic_t congestion_count; +/* Used to store internal freezer state */ +struct cgroup_freezer_state freezer; +/* ids of the ancestors at each level including self */ int ancestor_ids[]; };
include/linux/cgroup.h +46 -0
50 lines not on this page · raw message
include/linux/sched.h +4 -0
@@ -731,6 +731,10 @@ struct task_struct {#ifdef CONFIG_CGROUPS /* disallow userland-initiated cgroup migration */ unsigned no_cgroup_migration:1; +/* task is frozen by the cgroup freezer */ + unsigned frozen:1; +/* task is stopped (used by cgroup freezer) */ + unsigned stopped:1;#endif #ifdef CONFIG_BLK_CGROUP /* to be used once the psi infrastructure lands upstream. */
include/linux/sched/jobctl.h +2 -0
@@ -18,6 +18,7 @@ struct task_struct;#define JOBCTL_TRAP_NOTIFY_BIT 20/* trap for NOTIFY */ #define JOBCTL_TRAPPING_BIT 21/* switching to TRACED */ #define JOBCTL_LISTENING_BIT 22/* ptracer is listening for events */ +#define JOBCTL_TRAP_FREEZE_BIT 23/* trap for cgroup freezer */ #define JOBCTL_STOP_DEQUEUED (1UL << JOBCTL_STOP_DEQUEUED_BIT)#define JOBCTL_STOP_PENDING (1UL << JOBCTL_STOP_PENDING_BIT)
@@ -26,6 +27,7 @@ struct task_struct;#define JOBCTL_TRAP_NOTIFY (1UL << JOBCTL_TRAP_NOTIFY_BIT)#define JOBCTL_TRAPPING (1UL << JOBCTL_TRAPPING_BIT)#define JOBCTL_LISTENING (1UL << JOBCTL_LISTENING_BIT) +#define JOBCTL_TRAP_FREEZE (1UL << JOBCTL_TRAP_FREEZE_BIT)#define JOBCTL_TRAP_MASK (JOBCTL_TRAP_STOP | JOBCTL_TRAP_NOTIFY)#define JOBCTL_PENDING_MASK (JOBCTL_STOP_PENDING | JOBCTL_TRAP_MASK)
kernel/cgroup/Makefile +1 -1
@@ -1,5 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 -obj-y := cgroup.o rstat.o namespace.o cgroup-v1.o +obj-y := cgroup.o rstat.o namespace.o cgroup-v1.o freezer.o obj-$(CONFIG_CGROUP_FREEZER) += legacy_freezer.o obj-$(CONFIG_CGROUP_PIDS) += pids.o
kernel/cgroup/cgroup.c +103 -3
159 lines not on this page · raw message
kernel/cgroup/freezer.c new file +329 -0
329 lines not on this page · raw message
kernel/signal.c +88 -5
146 lines not on this page · raw message
Signature · 1 line
2.19.2
Re: [PATCH v6 4/7] cgroup: cgroup v2 freezer
Sorry, this version raced with my vacation, I missed it.
I'll try to read this code carefully but after a quick glance I have some concerns,
Quoted 6 lines · Roman Gushchin
kernel/cgroup/freezer.c new file +5
-0+static void cgroup_update_frozen (struct cgroup *cgrp) +{ +bool frozen; + +lockdep_assert_held (&css_set_lock);
kernel/cgroup/freezer.c line 63
Quoted 10 lines
kernel/cgroup/freezer.c new file +10
-0+ +/* +* If the cgroup has to be frozen (CGRP_FREEZE bit set), +* and all tasks are frozen or stopped, let's consider +* the cgroup frozen. Otherwise it's not frozen. +*/ + frozen =test_bit (CGRP_FREEZE , &cgrp->flags) && + cgrp->freezer.nr_frozen_tasks + + cgrp->freezer.nr_stopped_tasks == + cgrp->freezer.nr_tasks_to_freeze;
OK. Suppose that cgroup is frozen, CGRP_FROZEN is set, stopped == 0, to_freeze = frozen.
One of the task is killed, it calls leave_frozen(). If I read this code path correctly, only ->nr_frozen_tasks will be decremented, so "frozen" will be "false" when cgroup_update_frozen() is called.
Doesn't this mean that this cgroup will no longer be CGRP_FROZEN even after the killed task goes away completely?
Or. Suppose that another process picks a task from the CGRP_FROZEN cgroup and does PTRACE_ATTACH + PTRACE_INTERRUPT. IIUC, the tracee will only increment ->nr_stopped_tasks, it won't touch other counters. Again, cgroup won't be FROZEN until PTRACE_CONT'ed tracee does cgroup_leave_stopped() ? This looks strange at least.
SIGSTOP. IIUC, a frozen task sleeping in do_freezer_trap() won't stop. However if another thread has already called do_signal_stop(), the woken frozen task will react to JOBCTL_STOP_PENDING and stop. And do_signal_stop()->cgroup_enter_stopped() will "destroy" CGRP_FROZEN too, or I am totally confused.
OTOH, if you freeze a TASK_STOPPED task's cgroup, this task can react to SIGCONT, notify its parent, then freeze again. This is fine, but iiuc this cgroup won't be FROZEN in between, cgroup_file_notify() will be called twice...
Oleg.
Re: [PATCH v6 4/7] cgroup: cgroup v2 freezer
Quoted 4 lines · Oleg Nesterov
One of the task is killed, it calls
leave_frozen(). If I read this code path correctly, only ->nr_frozen_tasks will be decremented, so "frozen" will be "false" whencgroup_update_frozen()is called.
forgot to mention...
and I do not think cgroup_exit() can "fix" this, see another email I sent a minute ago...
Oleg.
Re: [PATCH v6 4/7] cgroup: cgroup v2 freezer
In reply to Oleg NesterovHi Oleg!
Thank you for looking into the patchset!
Yes, I think you're right: cgroup_exit() should check CGRP_FREEZE bit, not CGRP_FROZEN. Like cgroup_post_fork() does (a one-liner change below).
About spurious transitions (like frozen->non frozen->frozen on a task being SIGKILLed):
in early versions of the patchset I've tried to avoid them, but then following the Tejun's advice
switched over to expose them to a user. The logic behind is simple: if the state of the cgroup has been changed (a task is gone, for example), let's notify a user.
nr_tasks_to_freeze is simple a number of non-kthead tasks in the cgroup, which we do
keep actual only for freezing cgroups (to avoid an unnecessary overhead).
Thanks!
--
kernel/cgroup/cgroup.c +1 -1
@@ -5832,7 +5832,7 @@ void cgroup_exit(struct task_struct *tsk)css_set_move_task (tsk, cset,NULL , false); cset->nr_tasks--; -if (unlikely (test_bit (CGRP_FROZEN , &cset->dfl_cgrp->flags))) { +if (unlikely (cgroup_task_freeze (tsk))) {/* * Task frozen bit should be cleared at this moment, * and nr_frozen_task should be decreased.
пт, 25 янв. 2019 г. в 04:27, Oleg Nesterov <[email protected]>:
Quoted 54 lines
Sorry, this version raced with my vacation, I missed it.
I'll try to read this code carefully but after a quick glance I have some concerns,
Quoted 6 lines · Roman Gushchin
(quoted diff) +5
-0+static void cgroup_update_frozen(struct cgroup *cgrp) +{ + bool frozen; + + lockdep_assert_held(&css_set_lock);Review
Quoted 10 lines
(quoted diff) +10
-0+ + /* + * If the cgroup has to be frozen (CGRP_FREEZE bit set), + * and all tasks are frozen or stopped, let's consider + * the cgroup frozen. Otherwise it's not frozen. + */ + frozen = test_bit(CGRP_FREEZE, &cgrp->flags) && + cgrp->freezer.nr_frozen_tasks + + cgrp->freezer.nr_stopped_tasks == + cgrp->freezer.nr_tasks_to_freeze;OK. Suppose that cgroup is frozen,
CGRP_FROZENis set, stopped == 0,to_freeze= frozen.One of the task is killed, it calls
leave_frozen(). If I read this code path correctly, only ->nr_frozen_tasks will be decremented, so "frozen" will be "false" whencgroup_update_frozen()is called.Doesn't this mean that this cgroup will no longer be
CGRP_FROZENeven after the killed task goes away completely?Or. Suppose that another process picks a task from the
CGRP_FROZENcgroup and doesPTRACE_ATTACH+PTRACE_INTERRUPT. IIUC, the tracee will only increment ->nr_stopped_tasks, it won't touch other counters. Again, cgroup won't be FROZEN until PTRACE_CONT'ed tracee doescgroup_leave_stopped()? This looks strange at least.SIGSTOP. IIUC, a frozen task sleeping in
do_freezer_trap()won't stop. However if another thread has already calleddo_signal_stop(), the woken frozen task will react toJOBCTL_STOP_PENDINGand stop. And do_signal_stop()->cgroup_enter_stopped() will "destroy"CGRP_FROZENtoo, or I am totally confused.OTOH, if you freeze a
TASK_STOPPEDtask's cgroup, this task can react to SIGCONT, notify its parent, then freeze again. This is fine, but iiuc this cgroup won't be FROZEN in between,cgroup_file_notify()will be called twice...Oleg.
Re: [PATCH v6 4/7] cgroup: cgroup v2 freezer
Hi Roman,
Quoted 3 lines · Roman Gushchin
Yes, I think you're right:
cgroup_exit()should checkCGRP_FREEZEbit, notCGRP_FROZEN. Likecgroup_post_fork()does (a one-liner change below).
but this won't fix all problems? it seems that you missed my other concerns.
Firstly, this doesn't look consistent. Suppose a cgroup contains a single process sleeping in ptrace_stop(). Then it becomes CGRP_FROZEN right after "echo 1 > cgroup.freeze".
OTOH. if this single task sleeps in do_freezer_trap() and gets PTRACE_INTERRUPT, it will equally sleep ptrace_stop() but cgroup won't be CGRP_FROZEN. Never.
Worse, this looks just wrong. In the latter case, cgroup becomes CGRP_FROZEN right after a 2nd task migrates to this cgroup, before this new task calls do_freezer_trap() or cgroup_enter_stopped().
Quoted 7 lines
About spurious transitions (like
frozen->nonfrozen->frozenon a task being SIGKILLed):
in early versions of the patchset I've tried to avoid them, but then following the Tejun's advice
switched over to expose them to a user. The logic behind is simple: if the state of the cgroup has been changed (a task is gone, for example), let's notify a user.
OK, I won't argue...
actually I can't argue because I do not really understand why do we want a "killable" freezer, let alone ptraceable ;)
Oleg.
Re: [PATCH v6 4/7] cgroup: cgroup v2 freezer
Quoted 6 lines · Oleg Nesterov
Hi Roman,
Quoted 3 lines · Roman Gushchin
Yes, I think you're right:
cgroup_exit()should checkCGRP_FREEZEbit, notCGRP_FROZEN. Likecgroup_post_fork()does (a one-liner change below).
Hi Oleg!
Sorry for the late reply, I was out of work for some time... Now I'm fully back.
Quoted 7 lines
but this won't fix all problems? it seems that you missed my other concerns.
Firstly, this doesn't look consistent. Suppose a cgroup contains a single process sleeping in
ptrace_stop(). Then it becomesCGRP_FROZENright after "echo 1 > cgroup.freeze".
Quoted 6 lines
OTOH. if this single task sleeps in
do_freezer_trap()and getsPTRACE_INTERRUPT, it will equally sleepptrace_stop()but cgroup won't beCGRP_FROZEN. Never.Worse, this looks just wrong. In the latter case, cgroup becomes
CGRP_FROZENright after a 2nd task migrates to this cgroup, before this new task callsdo_freezer_trap()orcgroup_enter_stopped().
You're right. So, it looks like the problem is in the equation nr_tasks_frozen + nr_tasks_stopped == nr_tasks_to_freeze , because a task can be frozen and stopped simultaneously.
So, basically it has to benr_tasks_frozen + nr_tasks_stopped >= nr_tasks_to_freeze instead.
I'll cover it with an unit test, and will post v7 soon.
Quoted 11 lines
Quoted 10 lines
About spurious transitions (like
frozen->nonfrozen->frozenon a task being SIGKILLed):
in early versions of the patchset I've tried to avoid them, but then following the Tejun's advice
switched over to expose them to a user. The logic behind is simple: if the state of the cgroup has been changed (a task is gone, for example), let's notify a user.
Quoted 4 lines
OK, I won't argue...
actually I can't argue because I do not really understand why do we want a "killable" freezer, let alone ptraceable ;)
So the problem with the frozen state as in cgroup v1 that it's a very special and "non-natural" task state, which requires special handling in many places.
Just for an example, we're using oomd (userspace OOM handling daemon), which selects and kills one of the workloads in case of too high memory pressure. It should be able to kill all tasks in the selected cgroup, but we definitely don't want to let it to fiddle with cgroup controls to unfreeze the cgroup. Etc.
In other words, the cgroup freezer has a simple task of preventing processes in the given cgroup to consume CPU resources. Unlike the system-wide freezer, it shouldn't try to make a "snapshot", it just a non-goal.
Thanks!
Re: [PATCH v6 4/7] cgroup: cgroup v2 freezer
Quoted 7 lines · Roman Gushchin
Quoted 4 lines · Oleg Nesterov
Worse, this looks just wrong. In the latter case, cgroup becomes
CGRP_FROZENright after a 2nd task migrates to this cgroup, before this new task callsdo_freezer_trap()orcgroup_enter_stopped().
Quoted 6 lines
You're right. So, it looks like the problem is in the equation
nr_tasks_frozen+nr_tasks_stopped==nr_tasks_to_freeze, because a task can be frozen and stopped simultaneously.So, basically it has to be
nr_tasks_frozen+nr_tasks_stopped>=nr_tasks_to_freezeinstead.
It seems you didn't read the paragraph above, or I missed something...
How can "frozen + stopped >= to_freeze" fix the problem with the falsely true CGRP_FROZEN ?
Oleg.
Re: [PATCH v6 4/7] cgroup: cgroup v2 freezer
Quoted 12 lines · Oleg Nesterov
Quoted 11 lines · Roman Gushchin
Quoted 4 lines · Oleg Nesterov
Worse, this looks just wrong. In the latter case, cgroup becomes
CGRP_FROZENright after a 2nd task migrates to this cgroup, before this new task callsdo_freezer_trap()orcgroup_enter_stopped().You're right. So, it looks like the problem is in the equation
nr_tasks_frozen+nr_tasks_stopped==nr_tasks_to_freeze, because a task can be frozen and stopped simultaneously.
Quoted 7 lines
Quoted 2 lines
So, basically it has to be
nr_tasks_frozen+nr_tasks_stopped>=nr_tasks_to_freezeinstead.It seems you didn't read the paragraph above, or I missed something...
How can "frozen + stopped >=
to_freeze" fix the problem with the falsely trueCGRP_FROZEN?
It helps with the problem when cgroup is mistakenly reported as non-frozen, and adding a task makes it frozen due to increased nr_tasks_to_freeze.
But you're right, it's not correct. I have to think more how to make the accounting work correctly with stopped tasks.
Roman
Re: [PATCH v6 4/7] cgroup: cgroup v2 freezer
In reply to Roman GushchinQuoted 18 lines · Roman Gushchin
kernel/cgroup/freezer.c new file +17
-0+static void cgroup_do_freeze (struct cgroup *cgrp,bool freeze) +{ +struct css_task_iter it; +struct task_struct *task; + +lockdep_assert_held (&cgroup_mutex); + +spin_lock_irq (&css_set_lock); +if (freeze) { + cgrp->freezer.nr_tasks_to_freeze =__cgroup_task_count (cgrp); +set_bit (CGRP_FREEZE , &cgrp->flags); + }else { +clear_bit (CGRP_FREEZE , &cgrp->flags); + } +spin_unlock_irq (&css_set_lock); + +css_task_iter_start (&cgrp->self,0 , &it);
kernel/cgroup/freezer.c line 229
Quoted 10 lines
kernel/cgroup/freezer.c new file +10
-0+while ((task =css_task_iter_next (&it))) { +/* +* Ignore kernel threads here. Freezing cgroups containing +* kthreads isn't supported. +*/ +if (task->flags &PF_KTHREAD ) +continue ; +cgroup_freeze_task (task, freeze); + } +css_task_iter_end (&it);
I don't understand why this can race with exiting task. Or with SIGKILL which kills a task before it sets current->frozen.
How can we trust nr_tasks_to_freeze at all?
Yes you added cgroup_dec_tasks_to_freeze() into cgroup_exit(). But it won't be called if CGRP_FROZEN was not set yet, or because of "spurious" transitions caused by cgroup_inc/dec_frozen_cnt() called by this or other tasks.
it seems that cgroup_exit() should check CGRP_FREEZE instead...
Oleg.
PATCH v6 5/7 kselftests: cgroup: don't fail on cg_kill_all() error in cg_destroy()
In reply to Roman GushchinIf the cgroup destruction races with an exit() of a belonging process(es), cg_kill_all() may fail. It's not a good reason to make cg_destroy() fail and leave the cgroup in place, potentially causing next test runs to fail.
--- tools/testing/selftests/cgroup/cgroup_util.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
tools/testing/selftests/cgroup/cgroup_util.c +1 -3
@@ -227,9 +227,7 @@ int cg_destroy(const char *cgroup) retry: ret =rmdir (cgroup);if (ret && errno ==EBUSY ) { - ret =cg_killall (cgroup); -if (ret) -return ret; +cg_killall (cgroup);usleep (100 ); goto retry; }
Signature · 1 line
2.19.2
PATCH v6 6/7 kselftests: cgroup: add freezer controller self-tests
In reply to Roman GushchinThis patch implements 8 tests for the freezer controller for cgroup v2:
1) a simple test, which aims to freeze and unfreeze a cgroup with 100 processes
2) a more complicated tree test, which creates a hierarchy of cgroups, puts some processes in some cgroups, and tries to freeze and unfreeze different parts of the subtree
3) a forkbomb test: the test aims to freeze a forkbomb running in a cgroup, kill all tasks in the cgroup and remove the cgroup without the unfreezing.
4) rmdir test: the test creates two nested cgroups, freezes the parent one, checks that the child can be successfully removed, and a new child can be created
5) migration tests: the test checks migration of a task between frozen cgroups: from a frozen to a running, from a running to a frozen, and from a frozen to a frozen.
6) ptrace test: the test checks that it's possible to attach to a process in a frozen cgroup, get some information and detach, and the cgroup will remain frozen.
7) stopped test: the test checks that it's possible to freeze a cgroup with a stopped task
8) ptraced test: the test checks that it's possible to freeze a cgroup with a ptraced task
Expected output:
$ ./test_freezer ok 1 test_cgfreezer_simple ok 2 test_cgfreezer_tree ok 3 test_cgfreezer_forkbomb ok 4 test_cgrreezer_rmdir ok 5 test_cgfreezer_migrate ok 6 test_cgfreezer_ptrace ok 7 test_cgfreezer_stopped ok 8 test_cgfreezer_ptraced
--- tools/testing/selftests/cgroup/.gitignore | 1 + tools/testing/selftests/cgroup/Makefile | 2 + tools/testing/selftests/cgroup/cgroup_util.c | 81 +- tools/testing/selftests/cgroup/cgroup_util.h | 7 + tools/testing/selftests/cgroup/test_freezer.c | 821 ++++++++++++++++++ 5 files changed, 911 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/cgroup/test_freezer.c
tools/testing/selftests/cgroup/.gitignore +1 -0
@@ -1,2 +1,3 @@ test_memcontrol test_core +test_freezer
tools/testing/selftests/cgroup/Makefile +2 -0
@@ -5,8 +5,10 @@ all: TEST_GEN_PROGS = test_memcontrol TEST_GEN_PROGS += test_core +TEST_GEN_PROGS += test_freezer include ../lib.mk $(OUTPUT)/test_memcontrol: cgroup_util.c $(OUTPUT)/test_core: cgroup_util.c +$(OUTPUT)/test_freezer: cgroup_util.c
tools/testing/selftests/cgroup/cgroup_util.c +80 -1
102 lines not on this page · raw message
tools/testing/selftests/cgroup/cgroup_util.h +7 -0
@@ -18,6 +18,7 @@ static inline int values_close(long a, long b, int err)extern int cg_find_unified_root (char *root,size_t len);extern char *cg_name (const char *root,const char *name);extern char *cg_name_indexed (const char *root,const char *name,int index); +extern char *cg_control (const char *cgroup,const char *control);extern int cg_create (const char *cgroup);extern int cg_destroy (const char *cgroup); extern int cg_read(const char *cgroup, const char *control,
@@ -32,6 +33,7 @@ extern int cg_write(const char *cgroup, const char *control, char *buf);extern int cg_run (const char *cgroup,int (*fn)(const char *cgroup,void *arg),void *arg); +extern int cg_enter (const char *cgroup,int pid);extern int cg_enter_current (const char *cgroup); extern int cg_run_nowait(const char *cgroup, int (*fn)(const char *cgroup, void *arg),
@@ -41,3 +43,8 @@ extern int alloc_pagecache(int fd, size_t size);extern int alloc_anon (const char *cgroup,void *arg);extern int is_swap_enabled (void );extern int set_oom_adj_score (int pid,int score); +extern int cg_for_all_procs (const char *cgroup,int (*fn)(int pid,void *arg), +void *arg); +extern int cg_wait_for_proc_count (const char *cgroup,int count); +extern int cg_killall (const char *cgroup); +extern char proc_read_text (int pid,const char *item,char *buf,size_t size);
tools/testing/selftests/cgroup/test_freezer.c new file +821 -0
821 lines not on this page · raw message
Signature · 1 line
2.19.2
PATCH v6 7/7 cgroup: document cgroup v2 freezer interface
In reply to Roman GushchinDescribe cgroup v2 freezer interface in the cgroup v2 admin guide.
--- Documentation/admin-guide/cgroup-v2.rst | 27 +++++++++++++++++++++++++ 1 file changed, 27 insertions(+)
Documentation/admin-guide/cgroup-v2.rst +27 -0
@@ -864,6 +864,8 @@ All cgroup core files are prefixed with "cgroup." populated 1 if the cgroup or its descendants contains any live processes; otherwise, 0. + frozen + 1 if the cgroup is frozen; otherwise, 0. cgroup.max.descendants A read-write single value files. The default is "max".
@@ -897,6 +899,31 @@ All cgroup core files are prefixed with "cgroup." A dying cgroup can consume system resources not exceeding limits, which were active at the moment of cgroup deletion. + 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; when this action + is completed, the "frozen" value in the cgroup.events control file + will be updated to "1" and the corresponding notification will be + issued. + + A cgroup can be frozen either by its own settings, or by settings + of any ancestor cgroups. If any of ancestor cgroups is frozen, the + cgroup will remain frozen. + + Processes in the frozen cgroup can be killed by a fatal signal. + They also can enter and leave a frozen cgroup: either by an explicit + move by a user, or if freezing of the cgroup races with fork(). + If a process is moved to a frozen cgroup, it stops. If a process is + moved out of a frozen cgroup, it becomes running. + + Frozen status of a cgroup doesn't affect any cgroup tree operations: + it's possible to delete a frozen (and empty) cgroup, as well as + create new sub-cgroups. Controllers ===========
Signature · 1 line
2.19.2
Tejun Heo
maintainerQuoted 12 lines · Roman Gushchin
This patchset implements freezer for cgroup v2.
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, there is no separate controller, which has to be enabled, etc.
Patches (1), (2) and (3) are some preparational work, patch (4) contains the implementation, patch (5) is a small cgroup kselftest fix, patch (6) covers freezer adds 6 new kselftests to cover the freezer functionality. Patch (7) adds corresponding docs.
Quoted 7 lines
v6->v5:
- reverted to clearTIF_SIGPENDINGwith additional checks beforeschedule(), as proposed by Oleg Nesterov
- made cgroup v2 freezer working with the system freezer (by usingfreezable_schedule())
- make freezer working with SIGSTOPped and PTRACEd tasks
- added tests to cover freezing a cgroup with SIGSTOPped and PTRACEd tasks
Oleg, ping?
Thanks.
Signature · 1 line
tejun