freezer for cgroup v2

kernel/cgroup/freezer.c new file +13 -0

+void cgroup_leave_frozen(bool always_leave)
+{
+	struct cgroup *cgrp;
+
+	spin_lock_irq(&css_set_lock);
+	cgrp = task_dfl_cgroup(current);
+	if (always_leave || !test_bit(CGRP_FREEZE, &cgrp->flags)) {
+		cgroup_dec_frozen_cnt(cgrp);
+		cgroup_update_frozen(cgrp);
+		WARN_ON_ONCE(!current->frozen);
+		current->frozen = false;
+	}
+	spin_unlock_irq(&css_set_lock);

kernel/cgroup/freezer.c new file +4 -0

+static void cgroup_freeze_task(struct task_struct *task, bool freeze)
+{
+	unsigned long flags;
+

Quoted 14 lines · Roman Gushchin

kernel/cgroup/freezer.c new file +13 -0

+void cgroup_leave_frozen(bool always_leave)
+{
+	struct cgroup *cgrp;
+
+	spin_lock_irq(&css_set_lock);
+	cgrp = task_dfl_cgroup(current);
+	if (always_leave || !test_bit(CGRP_FREEZE, &cgrp->flags)) {
+		cgroup_dec_frozen_cnt(cgrp);
+		cgroup_update_frozen(cgrp);
+		WARN_ON_ONCE(!current->frozen);
+		current->frozen = false;
+	}
+	spin_unlock_irq(&css_set_lock);

kernel/cgroup/freezer.c line 148

Quoted 10 lines

kernel/cgroup/freezer.c new file +10 -0

+
+	if (unlikely(current->frozen)) {
+		/*
+		 * If the task remained in the frozen state,
+		 * make sure it won't reach userspace without
+		 * entering the signal handling loop.
+		 */
+		spin_lock_irq(&current->sighand->siglock);
+		recalc_sigpending();
+		spin_unlock_irq(&current->sighand->siglock);

I still can't understand this logic.

Once again, suppose we race with CGRP_FREEZE. If JOBCTL_TRAP_FREEZE is already set then signal_pending() must be already T and we do not need recalc_sigpending? If JOBCTL_TRAP_FREEZE is not set yet, how can recalc_sigpending() help?

Quoted 4 lines

kernel/cgroup/freezer.c new file +4 -0

+static void cgroup_freeze_task(struct task_struct *task, bool freeze)
+{
+	unsigned long flags;
+

kernel/cgroup/freezer.c line 169

Quoted 10 lines

kernel/cgroup/freezer.c new file +10 -0

+	/* If the task is about to die, don't bother with freezing it. */
+	if (!lock_task_sighand(task, &flags))
+		return;
+
+	if (freeze) {
+		task->jobctl |= JOBCTL_TRAP_FREEZE;
+		signal_wake_up(task, false);
+	} else {
+		task->jobctl &= ~JOBCTL_TRAP_FREEZE;
+		wake_up_process(task);

wake_up_interruptible() ?

kernel/signal.c bool get_signal(struct ksignal *ksig) · line 2489

Quoted 11 lines

static int ptrace_signal(int signr, kernel_siginfo_t *info) {

kernel/signal.c +4 -0

 	/*

@@ -2442,6 +2483,10 @@ bool get_signal(struct ksignal *ksig)
 		ksig->info.si_signo = signr = SIGKILL;
 		sigdelset(&current->pending.signal, SIGKILL);
 		recalc_sigpending();
+		current->jobctl &= ~JOBCTL_TRAP_FREEZE;
+		spin_unlock_irq(&sighand->siglock);
+		if (unlikely(cgroup_task_frozen(current)))
+			cgroup_leave_frozen(true);

Oh, and another leave_frozen below...

I feel this must be simplified somehow, but nothing comes to my mind right now.

kernel/signal.c bool get_signal(struct ksignal *ksig) · line 2519

Quoted 9 lines

kernel/signal.c +6 -0

+		/*
+		 * If the task is leaving the frozen state, let's update
+		 * cgroup counters and reset the frozen bit.
+		 */
+		if (unlikely(cgroup_task_frozen(current))) {
 			spin_unlock_irq(&sighand->siglock);
+			cgroup_leave_frozen(true);
 			goto relock;
 		}

afaics cgroup_leave_frozen(false) makes more sense here.

Oleg.

Anyway, I do not want to delay this feature. Even if I am right we can cleanup this code later. I see nothing really wrong, so no objections from me. Sorry for delay.

Quoted 14 lines · Roman Gushchin

kernel/cgroup/freezer.c new file +13 -0

+void cgroup_leave_frozen(bool always_leave)
+{
+	struct cgroup *cgrp;
+
+	spin_lock_irq(&css_set_lock);
+	cgrp = task_dfl_cgroup(current);
+	if (always_leave || !test_bit(CGRP_FREEZE, &cgrp->flags)) {
+		cgroup_dec_frozen_cnt(cgrp);
+		cgroup_update_frozen(cgrp);
+		WARN_ON_ONCE(!current->frozen);
+		current->frozen = false;
+	}
+	spin_unlock_irq(&css_set_lock);

kernel/cgroup/freezer.c line 148

Quoted 10 lines

kernel/cgroup/freezer.c new file +10 -0

+
+	if (unlikely(current->frozen)) {
+		/*
+		 * If the task remained in the frozen state,
+		 * make sure it won't reach userspace without
+		 * entering the signal handling loop.
+		 */
+		spin_lock_irq(&current->sighand->siglock);
+		recalc_sigpending();
+		spin_unlock_irq(&current->sighand->siglock);

I still can't understand this logic.

Once again, suppose we race with CGRP_FREEZE. If JOBCTL_TRAP_FREEZE is already set then signal_pending() must be already T and we do not need recalc_sigpending? If JOBCTL_TRAP_FREEZE is not set yet, how can recalc_sigpending() help?

Quoted 5 lines

kernel/cgroup/freezer.c new file +4 -0

+static void cgroup_freeze_task(struct task_struct *task, bool freeze)
+{
+	unsigned long flags;
+

kernel/cgroup/freezer.c line 169

Quoted 10 lines

kernel/cgroup/freezer.c new file +10 -0

+	/* If the task is about to die, don't bother with freezing it. */
+	if (!lock_task_sighand(task, &flags))
+		return;
+
+	if (freeze) {
+		task->jobctl |= JOBCTL_TRAP_FREEZE;
+		signal_wake_up(task, false);
+	} else {
+		task->jobctl &= ~JOBCTL_TRAP_FREEZE;
+		wake_up_process(task);

wake_up_interruptible() ?

kernel/signal.c bool get_signal(struct ksignal *ksig) · line 2489

Quoted 12 lines

static int ptrace_signal(int signr, kernel_siginfo_t *info) {

kernel/signal.c +4 -0

 	/*

@@ -2442,6 +2483,10 @@ bool get_signal(struct ksignal *ksig)
 		ksig->info.si_signo = signr = SIGKILL;
 		sigdelset(&current->pending.signal, SIGKILL);
 		recalc_sigpending();
+		current->jobctl &= ~JOBCTL_TRAP_FREEZE;
+		spin_unlock_irq(&sighand->siglock);
+		if (unlikely(cgroup_task_frozen(current)))
+			cgroup_leave_frozen(true);

Oh, and another leave_frozen below...

I feel this must be simplified somehow, but nothing comes to my mind right now.

kernel/signal.c bool get_signal(struct ksignal *ksig) · line 2519

Quoted 9 lines

kernel/signal.c +6 -0

+		/*
+		 * If the task is leaving the frozen state, let's update
+		 * cgroup counters and reset the frozen bit.
+		 */
+		if (unlikely(cgroup_task_frozen(current))) {
 			spin_unlock_irq(&sighand->siglock);
+			cgroup_leave_frozen(true);
 			goto relock;
 		}

afaics cgroup_leave_frozen(false) makes more sense here.

Quoted 4 lines

Once again, suppose we race with CGRP_FREEZE. If JOBCTL_TRAP_FREEZE is already set then signal_pending() must be already T and we do not need recalc_sigpending? If JOBCTL_TRAP_FREEZE is not set yet, how can recalc_sigpending() help?

This is paired with cgroup_task_frozen() check in recalc_sigpending_tsk().

Quoted 8 lines

Quoted 8 lines

kernel/cgroup/freezer.c new file +8 -0

+static void cgroup_freeze_task(struct task_struct *task, bool freeze)
+{
+	unsigned long flags;
+
+	/* If the task is about to die, don't bother with freezing it. */
+	if (!lock_task_sighand(task, &flags))
+		return;
+

Quoted 8 lines

kernel/cgroup/freezer.c line 169

Quoted 6 lines

kernel/cgroup/freezer.c new file +6 -0

+	if (freeze) {
+		task->jobctl |= JOBCTL_TRAP_FREEZE;
+		signal_wake_up(task, false);
+	} else {
+		task->jobctl &= ~JOBCTL_TRAP_FREEZE;
+		wake_up_process(task);

wake_up_interruptible() ?

Wait_up_interruptible() is supposed to work with a workqueue,
but here there is nothing like this. Probably, I didn't understand your idea. Can you, please, elaborate a bit more?

Quoted 5 lines

Quoted 5 lines

static int ptrace_signal(int signr, kernel_siginfo_t *info) {

kernel/signal.c +0 -0

 	/*

@@ -2442,6 +2483,10 @@ bool get_signal(struct ksignal *ksig)
 		ksig->info.si_signo = signr = SIGKILL;

Quoted 8 lines

kernel/signal.c bool get_signal(struct ksignal *ksig) · line 2489

Quoted 6 lines

kernel/signal.c +4 -0

 		sigdelset(&current->pending.signal, SIGKILL);
 		recalc_sigpending();
+		current->jobctl &= ~JOBCTL_TRAP_FREEZE;
+		spin_unlock_irq(&sighand->siglock);
+		if (unlikely(cgroup_task_frozen(current)))
+			cgroup_leave_frozen(true);

Oh, and another leave_frozen below...

Yeah, because of this new "goto fatal" shortcut.

Quoted 7 lines

kernel/signal.c bool get_signal(struct ksignal *ksig) · line 2519

Quoted 5 lines

kernel/signal.c +2 -0

+		if (unlikely(cgroup_task_frozen(current))) {
 			spin_unlock_irq(&sighand->siglock);
+			cgroup_leave_frozen(true);
 			goto relock;
 		}

afaics cgroup_leave_frozen(false) makes more sense here.

Why? I don't see any reasons why the task should remain in the frozen state after this point.

Quoted 5 lines · Roman Gushchin

Quoted 4 lines

Once again, suppose we race with CGRP_FREEZE. If JOBCTL_TRAP_FREEZE is already set then signal_pending() must be already T and we do not need recalc_sigpending? If JOBCTL_TRAP_FREEZE is not set yet, how can recalc_sigpending() help?

Quoted 1 line

This is paired with cgroup_task_frozen() check in recalc_sigpending_tsk().

Ooh, I didn't notice this version added cgroup_task_frozen() into recalc_sigpending_tsk() ...

Honestly, I don't like this. But see another email I sent, we can cleanup this code later.

Quoted 18 lines

Quoted 17 lines

Quoted 5 lines

kernel/cgroup/freezer.c new file +4 -0

+static void cgroup_freeze_task(struct task_struct *task, bool freeze)
+{
+	unsigned long flags;
+

kernel/cgroup/freezer.c line 169

Quoted 10 lines

kernel/cgroup/freezer.c new file +10 -0

+	/* If the task is about to die, don't bother with freezing it. */
+	if (!lock_task_sighand(task, &flags))
+		return;
+
+	if (freeze) {
+		task->jobctl |= JOBCTL_TRAP_FREEZE;
+		signal_wake_up(task, false);
+	} else {
+		task->jobctl &= ~JOBCTL_TRAP_FREEZE;
+		wake_up_process(task);

wake_up_interruptible() ?

Quoted 3 lines

Wait_up_interruptible() is supposed to work with a workqueue,
but here there is nothing like this. Probably, I didn't understand your idea. Can you, please, elaborate a bit more?

Not sure I understand... We need to wake up the task if it sleeps in do_freezer_trap(), right? do_freezer_trap() uses TASK_INTERRUPTIBLE, so why can't wake_up_interruptible() == __wake_up(TASK_INTERRUPTIBLE) work?

Quoted 15 lines

Quoted 14 lines

kernel/signal.c bool get_signal(struct ksignal *ksig) · line 2489

Quoted 12 lines

static int ptrace_signal(int signr, kernel_siginfo_t *info) {

kernel/signal.c +4 -0

 	/*

@@ -2442,6 +2483,10 @@ bool get_signal(struct ksignal *ksig)
 		ksig->info.si_signo = signr = SIGKILL;
 		sigdelset(&current->pending.signal, SIGKILL);
 		recalc_sigpending();
+		current->jobctl &= ~JOBCTL_TRAP_FREEZE;
+		spin_unlock_irq(&sighand->siglock);
+		if (unlikely(cgroup_task_frozen(current)))
+			cgroup_leave_frozen(true);

Oh, and another leave_frozen below...

Quoted 1 line

Yeah, because of this new "goto fatal" shortcut.

I understand, but the code doesn't look nice... but again, I can't suggest anything better at least right now, so please forget.

Quoted 8 lines

Quoted 7 lines

kernel/signal.c bool get_signal(struct ksignal *ksig) · line 2519

Quoted 5 lines

kernel/signal.c +2 -0

+		if (unlikely(cgroup_task_frozen(current))) {
 			spin_unlock_irq(&sighand->siglock);
+			cgroup_leave_frozen(true);
 			goto relock;
 		}

afaics cgroup_leave_frozen(false) makes more sense here.

Quoted 2 lines

Why? I don't see any reasons why the task should remain in the frozen state after this point.

But cgroup_leave_frozen(false) will equally clear ->frozen if !CGRP_FREEZE ? OTOH, if CGRP_FREEZE is set again, why do we need to clear ->frozen?

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

wake_up_interruptible() ?

Wait_up_interruptible() is supposed to work with a workqueue,
but here there is nothing like this. Probably, I didn't understand your idea. Can you, please, elaborate a bit more?

Quoted 3 lines

Not sure I understand... We need to wake up the task if it sleeps in do_freezer_trap(), right? do_freezer_trap() uses TASK_INTERRUPTIBLE, so why can't wake_up_interruptible() == __wake_up(TASK_INTERRUPTIBLE) work?

Right, but __wake_up is supposed to wake threads blocked on a waitqueue:

Quoted 11 lines

Quoted 10 lines

Quoted 7 lines

kernel/signal.c bool get_signal(struct ksignal *ksig) · line 2519

Quoted 5 lines

kernel/signal.c +2 -0

+		if (unlikely(cgroup_task_frozen(current))) {
 			spin_unlock_irq(&sighand->siglock);
+			cgroup_leave_frozen(true);
 			goto relock;
 		}

afaics cgroup_leave_frozen(false) makes more sense here.

Why? I don't see any reasons why the task should remain in the frozen state after this point.

Quoted 2 lines

But cgroup_leave_frozen(false) will equally clear ->frozen if !CGRP_FREEZE ? OTOH, if CGRP_FREEZE is set again, why do we need to clear ->frozen?

Hm, it might work too, but I'm not sure I like it more. IMO, the best option is to have a single cgroup_leave_frozen(true) in signal.c, it's just simpler. If a user changed the desired state of cgroup twice, there is no need to avoid state transitions. Or maybe I don't see it yet.

Quoted 8 lines · Roman Gushchin

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

wake_up_interruptible() ?

Wait_up_interruptible() is supposed to work with a workqueue,
but here there is nothing like this. Probably, I didn't understand your idea. Can you, please, elaborate a bit more?

Quoted 5 lines

Quoted 3 lines

Not sure I understand... We need to wake up the task if it sleeps in do_freezer_trap(), right? do_freezer_trap() uses TASK_INTERRUPTIBLE, so why can't wake_up_interruptible() == __wake_up(TASK_INTERRUPTIBLE) work?

Right, but __wake_up is supposed to wake threads blocked on a waitqueue:

Ugh sorry ;) of course I meant wake_up_state(task, TASK_INTERRUPTIBLE).

Quoted 15 lines

Quoted 14 lines

Quoted 11 lines

Quoted 8 lines

kernel/signal.c bool get_signal(struct ksignal *ksig) · line 2519

Quoted 6 lines

kernel/signal.c +2 -0

+		if (unlikely(cgroup_task_frozen(current))) {
 			spin_unlock_irq(&sighand->siglock);
+			cgroup_leave_frozen(true);
 			goto relock;
 		}

afaics cgroup_leave_frozen(false) makes more sense here.

Why? I don't see any reasons why the task should remain in the frozen state after this point.

But cgroup_leave_frozen(false) will equally clear ->frozen if !CGRP_FREEZE ? OTOH, if CGRP_FREEZE is set again, why do we need to clear ->frozen?

Quoted 4 lines

Hm, it might work too, but I'm not sure I like it more. IMO, the best option is to have a single cgroup_leave_frozen(true) in signal.c, it's just simpler. If a user changed the desired state of cgroup twice, there is no need to avoid state transitions. Or maybe I don't see it yet.

Then why do we need cgroup_leave_frozen(false) in wait_for_vfork_done() ? How does it differ from get_signal() ?

If nothing else. Suppose that wait_for_vfork_done() calls leave(false) and this races with freezer, CGRP_FREEZE is already set but JOBCTL_TRAP_FREEZE is not.

This sets TIF_SIGPENDING to ensure the task won't return to user mode, thus it calls get_signal().

get_signal() doesn't see JOBCTL_TRAP_FREEZE, it notices ->frozen == T and does cgroup_leave_frozen(true) which clears ->frozen.

Then the task calls dequeue_signal(), clears TIF_SIGPENDING and returns to user mode?

Quoted 6 lines

Quoted 5 lines

Hm, it might work too, but I'm not sure I like it more. IMO, the best option is to have a single cgroup_leave_frozen(true) in signal.c, it's just simpler. If a user changed the desired state of cgroup twice, there is no need to avoid state transitions. Or maybe I don't see it yet.

Quoted 2 lines

Then why do we need cgroup_leave_frozen(false) in wait_for_vfork_done() ? How does it differ from get_signal() ?

We need it because sleeping in vfork is a special state which we want to account as frozen. And if the parent process wakes up while the cgroup is frozen (because of the child death, for example), we want to push it into the "proper" frozen state without changing the state of the cgroup.

Quoted 4 lines

If nothing else. Suppose that wait_for_vfork_done() calls leave(false) and this races with freezer, CGRP_FREEZE is already set but JOBCTL_TRAP_FREEZE is not.

Quoted 8 lines

This sets TIF_SIGPENDING to ensure the task won't return to user mode, thus it calls get_signal().

get_signal() doesn't see JOBCTL_TRAP_FREEZE, it notices ->frozen == T and does cgroup_leave_frozen(true) which clears ->frozen.

Then the task calls dequeue_signal(), clears TIF_SIGPENDING and returns to user mode?

Got it, a good catch! So if the freezer races with vfork() completion, we might have a spurious frozen->unfrozen->frozen transition of the cgroup state.

Switching to cgroup_leave_frozen(false) seems to solve it, but I'm slightly concerned that we're basically putting the task in a busy loop between the setting CGRP_FREEZE and setting TRAP_FREEZE.

Quoted 6 lines · Roman Gushchin

Quoted 6 lines

Quoted 5 lines

Hm, it might work too, but I'm not sure I like it more. IMO, the best option is to have a single cgroup_leave_frozen(true) in signal.c, it's just simpler. If a user changed the desired state of cgroup twice, there is no need to avoid state transitions. Or maybe I don't see it yet.

Quoted 7 lines

Quoted 2 lines

Then why do we need cgroup_leave_frozen(false) in wait_for_vfork_done() ? How does it differ from get_signal() ?

We need it because sleeping in vfork is a special state which we want to account as frozen. And if the parent process wakes up while the cgroup is frozen (because of the child death, for example), we want to push it into the "proper" frozen state without changing the state of the cgroup.

Again, I do not see how vfork() differs from get_signal() in this respect.

Let me provide another example. A TASK_STOPPED task reacts to SIGCONT and returns to get_signal(), current->frozen is true.

If this races with CGRP_FREEZE, the task should not return to user-space, just like vfork(). I see no difference.

They differ in that wait_for_vfork_done() should guarentee TIF_SIGPENDING in this case, but this is another story...

Quoted 17 lines

Quoted 5 lines

If nothing else. Suppose that wait_for_vfork_done() calls leave(false) and this races with freezer, CGRP_FREEZE is already set but JOBCTL_TRAP_FREEZE is not.

Quoted 8 lines

This sets TIF_SIGPENDING to ensure the task won't return to user mode, thus it calls get_signal().

get_signal() doesn't see JOBCTL_TRAP_FREEZE, it notices ->frozen == T and does cgroup_leave_frozen(true) which clears ->frozen.

Then the task calls dequeue_signal(), clears TIF_SIGPENDING and returns to user mode?

Got it, a good catch! So if the freezer races with vfork() completion, we might have a spurious frozen->unfrozen->frozen transition of the cgroup state.

Quoted 3 lines

Switching to cgroup_leave_frozen(false) seems to solve it, but I'm slightly concerned that we're basically putting the task in a busy loop between the setting CGRP_FREEZE and setting TRAP_FREEZE.

Yes, yes. Didn't I say I dislike the new ->frozen check in recalc() ? ;)

OK, how about the ABSOLUTELY UNTESTED patch below? For the start.

Quoted 2 lines · Oleg Nesterov

OK, how about the ABSOLUTELY UNTESTED patch below? For the start.

It looks good to me (and all freezer selftests pass).

Just to be sure, is it a solution to avoid the busy loop in the signal handling loop, right?

Because it doesn't allow to drop the ->frozen check from recalc().

The JOBCTL_TRAP_FREEZE check without siglock initially looked dangerous to me, but after some thoughts I didn't find any case when it's wrong.

Do you prefer me to master a patch

Review void cgroup_exit(struct task_struct *tsk) · line 5934

Quoted 11 lines · Roman Gushchin

(quoted diff) +6 -0

@@ -5830,6 +5926,12 @@ void cgroup_exit(struct task_struct *tsk)
 		spin_lock_irq(&css_set_lock);
 		css_set_move_task(tsk, cset, NULL, false);
 		cset->nr_tasks--;
+
+		if (unlikely(cgroup_task_frozen(tsk)))
+			cgroup_freezer_frozen_exit(tsk);
+		else if (unlikely(cgroup_task_freeze(tsk)))
+			cgroup_update_frozen(task_dfl_cgroup(tsk));
+

of the patchset. In the current iteration I'd replace it with:

	WARN_ON_ONCE(cgroup_task_frozen(tsk));

just to make sure we're not leaking the frozen bit. Do you agree?

This patch implements 9 tests for the freezer controller for cgroup v2:

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.

Hi Roman,

Just want to share information here on what we notice on running this test case,

Quoted 3 lines

This patch implements 9 tests for the freezer controller for cgroup v2:

...

Quoted 3 lines

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.

selftests cgroup test_freezer failed because of the sys entry path not found.

Cgroup /sys/fs/cgroup/unified/cg_test_ptrace isn't frozen
/sys/fs/cgroup/unified/cg_test_ptrace: isn't_frozen #

# not ok 6 test_cgfreezer_ptrace

This test case fails intermittently.

The interaction between ptrace and freezer is complicated (as ptrace in general),so there are known cases when spurious cgroup transitions (frozen <-> non frozen <-> frozen ) can happen.

Does it create any difficulties? If so, I'll send a diff to ignore the result of this test for now.

Quoted 8 lines

Quoted 2 lines

This patch implements 9 tests for the freezer controller for cgroup v2:

...

Quoted 3 lines

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.

selftests cgroup test_freezer failed because of the sys entry path not found.

Can you, please, elaborate on this?

Hi Roman,

Quoted 3 lines

The interaction between ptrace and freezer is complicated (as ptrace in general),so there are known cases when spurious cgroup transitions (frozen <-> non frozen <-> frozen ) can happen.

When test ran for 8 times it got failed 5 times.
I have noticed intermittent failure on x86_64, arm64 hikey device and qemu_arm64.

Quoted 4 lines

Does it create any difficulties? If so, I'll send a diff to ignore the result of this test for now.

No difficulties. I will mark this test case as known failure.

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. Patchse (7) and (8) adding tracing points to simplify the debugging process. Patch (9) adds corresponding docs.