cpusets: allow PF_THREAD_BOUND kworkers to escape from a cpuset

kworkers can be born in a cpuset, leaving them adrift on an unsinkable ship. Allow them to be moved to the root cpuset so the cpuset can be destroyed.

Signed-off-by Mike Galbraith <[email protected]>

kernel/cpuset.c +0 -0

 		return -EINVAL;
 
 	return 0;

To make the code more self-explanatory, I think this is a bit better:

	if (... && cont != cont->top_cgroup)

Done, your ACK added as well.

kworkers can be born in a cpuset, leaving them adrift on an unsinkable ship. Allow them to be moved to the root cpuset so the cpuset can be destroyed.

Signed-off-by Mike Galbraith <[email protected]>

Acked-by Li Zefan <[email protected]>

kernel/cpuset.c +1 -1

index 10131fd..b26f4c4 100644
@@ -1384,7 +1384,7 @@ static int cpuset_can_attach(struct cgroup_subsys *ss, struct cgroup *cont,
 	 * set_cpus_allowed_ptr() on all attached tasks before cpus_allowed may
 	 * be changed.
 	 */
-	if (tsk->flags & PF_THREAD_BOUND)
+	if (tsk->flags & PF_THREAD_BOUND && cont != cont->top_cgroup)
 		return -EINVAL;
 
 	return 0;

Quoted 5 lines · Mike Galbraith

Done, your ACK added as well.

kworkers can be born in a cpuset, leaving them adrift on an unsinkable ship. Allow them to be moved to the root cpuset so the cpuset can be destroyed.

Thanks Li for the cc since I introduced this flag.

Does this even work?

You've modified cpuset_can_attach() to allow the attach for the cgroup interface, but the actual function that attaches the task in the cpuset code should fail since it does set_cpus_allowed_ptr() which should return -EINVAL because of the PF_THREAD_BOUND. That should have emitted a WARN_ON() if this patch was tested.

kworkers can always move themselves to the root cpuset, so that's probably the better way of handling this than requiring userspace to do so.

And it seems like the workqueue code has a comment specifically about cpu hotplug and why changing their cpumask shouldn't be allowed that was added by Tejun Heo in db7bccf45cb8 ("workqueue: reimplement CPU hotplugging support using trustee"). So let's cc him here as well at his non-kernel.org address.

Quoted 11 lines · David Rientjes

Quoted 5 lines · Mike Galbraith

Done, your ACK added as well.

kworkers can be born in a cpuset, leaving them adrift on an unsinkable ship. Allow them to be moved to the root cpuset so the cpuset can be destroyed.

Thanks Li for the cc since I introduced this flag.

Does this even work?

Yup, but..

Quoted 5 lines

You've modified cpuset_can_attach() to allow the attach for the cgroup interface, but the actual function that attaches the task in the cpuset code should fail since it does set_cpus_allowed_ptr() which should return -EINVAL because of the PF_THREAD_BOUND. That should have emitted a WARN_ON() if this patch was tested.

..you're right that it warns. It was tested, but I didn't notice that it had griped at me.

Quoted 2 lines

kworkers can always move themselves to the root cpuset, so that's probably the better way of handling this than requiring userspace to do so.

kworker is sleeping in a cpuset that the user wants to depopulate and destroy. I wasn't requiring the user to do that, was allowing him to.

cpusets: allow PF_THREAD_BOUND kworkers to escape from a cpuset

kworkers can be born in a cpuset, leaving them adrift on an unsinkable ship. Allow them to be moved to the root cpuset so the cpuset can be destroyed

Signed-off-by Mike Galbraith <[email protected]>

Acked-by Li Zefan <[email protected]>

kernel/cpuset.c +4 -1

index 10131fd..3769f9e 100644
@@ -1384,7 +1384,7 @@ static int cpuset_can_attach(struct cgroup_subsys *ss, struct cgroup *cont,
 	 * set_cpus_allowed_ptr() on all attached tasks before cpus_allowed may
 	 * be changed.
 	 */
-	if (tsk->flags & PF_THREAD_BOUND)
+	if (tsk->flags & PF_THREAD_BOUND && cont != cont->top_cgroup)
 		return -EINVAL;
 
 	return 0;

@@ -1426,9 +1426,14 @@ static void cpuset_attach_task(struct cgroup *cont, struct task_struct *tsk)
 	/*
 	 * can_attach beforehand should guarantee that this doesn't fail.
 	 * TODO: have a better way to handle failure here
+	 * 
+	 * Special case: bound kthreads born in a cpuset may be moved to
+	 * the top level cpuset without attempting to diddle their mask.

Quoted 7 lines · Mike Galbraith

cpusets: allow PF_THREAD_BOUND kworkers to escape from a cpuset

kworkers can be born in a cpuset, leaving them adrift on an unsinkable ship. Allow them to be moved to the root cpuset so the cpuset can be destroyed

Signed-off-by Mike Galbraith <[email protected]>

Acked-by Li Zefan <[email protected]>

Did Li ack this version?

Quoted 28 lines

kernel/cpuset.c +8 -3

index 10131fd..3769f9e 100644
@@ -1384,7 +1384,7 @@ static int cpuset_can_attach(struct cgroup_subsys *ss, struct cgroup *cont,
 	 * set_cpus_allowed_ptr() on all attached tasks before cpus_allowed may
 	 * be changed.
 	 */
-	if (tsk->flags & PF_THREAD_BOUND)
+	if (tsk->flags & PF_THREAD_BOUND && cont != cont->top_cgroup)
 		return -EINVAL;
 
 	return 0;

@@ -1426,9 +1426,14 @@ static void cpuset_attach_task(struct cgroup *cont, struct task_struct *tsk)
 	/*
 	 * can_attach beforehand should guarantee that this doesn't fail.
 	 * TODO: have a better way to handle failure here
+	 * 
+	 * Special case: bound kthreads born in a cpuset may be moved to
+	 * the top level cpuset without attempting to diddle their mask.
 	 */
-	err = set_cpus_allowed_ptr(tsk, cpus_attach);
-	WARN_ON_ONCE(err);
+	if (!(tsk->flags & PF_THREAD_BOUND && cont == cont->top_cgroup)) {
+		err = set_cpus_allowed_ptr(tsk, cpus_attach);
+		WARN_ON_ONCE(err);
+	}
 

kernel/cpuset.c static void cpuset_attach_task(struct cgroup *cont, struct task_struct *tsk) · line 1439

Quoted 2 lines

kernel/cpuset.c +0 -0

 	cpuset_change_task_nodemask(tsk, &cpuset_attach_nodemask_to);
 	cpuset_update_task_spread_flag(cs, tsk);

This doesn't make any sense, the user can now change the cpumask of the kworker with cpusets but not with sched_setaffinity().

PF_THREAD_BOUND is set specifically so threads cannot move from the cpu that they are bound to, that's why the cpuset code and sched_setaffinity() reject such a configuration.

So the problem isn't in the cpuset code or
scheduler at all, you would need to deal with this in the kworker code by either not setting PF_THREAD_BOUND (which, according to the comment, Tejun thinks is pretty important) or manage the worker threads in a way such that the new cpumask (all cpus, since it's in the root cpuset) actually make sense for that kworker. The cpuset code won't care if the kworker has a cpumask of all online cpus.

I don't see why it's a kworker code problem. The kworker code couldn't care less about cpusets. But I don't care who fixes it or how.

cpusets: disallow moving kthreadd into a cpuset.

If kthreadd is moved into a cpuset, it's child may then acquire PF_THREAD_BOUND and become trapped, making it's cpuset immortal.

Signed-off-by Mike Galbraith <[email protected]>

kernel/cpuset.c +1 -0

index 10131fd..0d9cd04 100644
@@ -59,6 +59,7 @@
 #include <linux/mutex.h>
 #include <linux/workqueue.h>
 #include <linux/cgroup.h>
+#include <linux/kthread.h>
 
 /*
  * Workqueue for cpuset related tasks.

@@ -1382,9 +1383,10 @@ static int cpuset_can_attach(struct cgroup_subsys *ss, struct cgroup *cont,
 	 * set of allowed nodes is unnecessary.  Thus, cpusets are not
 	 * applicable for such threads.  This prevents checking for success of

Quoted 12 lines

kernel/cpuset.c +3 -2

@@ -1382,9 +1383,10 @@ static int cpuset_can_attach(struct cgroup_subsys *ss, struct cgroup *cont,
 	 * set of allowed nodes is unnecessary.  Thus, cpusets are not
 	 * applicable for such threads.  This prevents checking for success of
 	 * set_cpus_allowed_ptr() on all attached tasks before cpus_allowed may
-	 * be changed.
+	 * be changed.  We also disallow attaching kthreadd, to prevent it's
+	 * child from becoming trapped should it then acquire PF_THREAD_BOUND.
 	 */
-	if (tsk->flags & PF_THREAD_BOUND)
+	if (tsk->flags & PF_THREAD_BOUND || tsk == kthreadd_task)
 		return -EINVAL;
 

kernel/cpuset.c static int cpuset_can_attach(struct cgroup_subsys *ss, struct cgroup *cont, · line 1392

Quoted 1 line

kernel/cpuset.c +0 -0

 	return 0;

I like this much better, let's wait to hear from Tejun because he may shead some light on whether PF_THREAD_BOUND is really necessary for kworkers at all times.

If cpusets doesn't want to let PF_THREAD_BOUND threads out, how about cpusets not letting userland scripts attach kthreadd instead?

cpusets: disallow moving kthreadd into a cpuset.

If kthreadd is moved into a cpuset, it's child may then acquire PF_THREAD_BOUND and become trapped, making it's cpuset immortal.

Signed-off-by Mike Galbraith <[email protected]>

kernel/cpuset.c +4 -2

index 10131fd..0d9cd04 100644
@@ -59,6 +59,7 @@
 #include <linux/mutex.h>
 #include <linux/workqueue.h>
 #include <linux/cgroup.h>
+#include <linux/kthread.h>
 
 /*
  * Workqueue for cpuset related tasks.

@@ -1382,9 +1383,10 @@ static int cpuset_can_attach(struct cgroup_subsys *ss, struct cgroup *cont,
 	 * set of allowed nodes is unnecessary.  Thus, cpusets are not
 	 * applicable for such threads.  This prevents checking for success of
 	 * set_cpus_allowed_ptr() on all attached tasks before cpus_allowed may
-	 * be changed.
+	 * be changed.  We also disallow attaching kthreadd, to prevent it's
+	 * child from becoming trapped should it then acquire PF_THREAD_BOUND.
 	 */
-	if (tsk->flags & PF_THREAD_BOUND)
+	if (tsk->flags & PF_THREAD_BOUND || tsk == kthreadd_task)
 		return -EINVAL;
 
 	return 0;

Maybe the below (which seems to have been stillborn) should be done to cgroups as well. Postmortem: kthreadd is attached to a cgroup with no rt_runtime allocated, gives birth to severely handicapped kstop threads, humongous crash dump follows.

Fiddling with kthreadd is user error, but since it makes no sense to move the thing, why not just say no, and save the user's toes some needless wear and tear.

Quoted 4 lines

If cpusets doesn't want to let PF_THREAD_BOUND threads out, how about cpusets not letting userland scripts attach kthreadd instead?

cpusets: disallow moving kthreadd into a cpuset.

Quoted 5 lines · Mike Galbraith

Maybe the below (which seems to have been stillborn) should be done to cgroups as well. Postmortem: kthreadd is attached to a cgroup with no rt_runtime allocated, gives birth to severely handicapped kstop threads, humongous crash dump follows.

Quoted 8 lines

Fiddling with kthreadd is user error, but since it makes no sense to move the thing, why not just say no, and save the user's toes some needless wear and tear.

Quoted 4 lines

If cpusets doesn't want to let PF_THREAD_BOUND threads out, how about cpusets not letting userland scripts attach kthreadd instead?

cpusets: disallow moving kthreadd into a cpuset.

So how about this, both dirt simple and effective.

cpusets, cgroups: disallow attaching kthreadd

Allowing kthreadd to be moved to a non-root group makes no sense, it being a global resource, and needlessly leads unsuspecting users toward trouble.

1. An RT workqueue worker thread spawned in a task group with no rt_runtime allocated is not schedulable. Simple user error, but harmful to the box.

2. A worker thread which acquires PF_THREAD_BOUND can never leave a cpuset, rendering the cpuset immortal.

Save the user some unexpected trouble, just say no.

Signed-off-by Mike Galbraith <[email protected]>

---
 kernel/cpuset.c |    6 ++++--
 kernel/sched.c  |    9 +++++++++
 2 files changed, 13 insertions(+), 2 deletions(-)

Index: linux-3.0-tip/kernel/cpuset.c
===================================================================

kernel/cpuset.c +4 -2

@@ -59,6 +59,7 @@
 #include <linux/mutex.h>
 #include <linux/workqueue.h>
 #include <linux/cgroup.h>
+#include <linux/kthread.h>
 
 /*
  * Workqueue for cpuset related tasks.

@@ -1382,9 +1383,10 @@ static int cpuset_can_attach(struct cgro
 	 * set of allowed nodes is unnecessary.  Thus, cpusets are not
 	 * applicable for such threads.  This prevents checking for success of
 	 * set_cpus_allowed_ptr() on all attached tasks before cpus_allowed may
-	 * be changed.
+	 * be changed.  We also disallow attaching kthreadd, to prevent it's
+	 * child from becoming trapped should it then acquire PF_THREAD_BOUND.
 	 */
-	if (tsk->flags & PF_THREAD_BOUND)
+	if (tsk->flags & PF_THREAD_BOUND || tsk == kthreadd_task)
 		return -EINVAL;
 
 	return 0;

Index: linux-3.0-tip/kernel/sched.c
===================================================================

kernel/sched.c +9 -0

@@ -9132,6 +9132,15 @@ cpu_cgroup_destroy(struct cgroup_subsys
 static int
 cpu_cgroup_can_attach_task(struct cgroup *cgrp, struct task_struct *tsk)
 {
+	/*
+	 * kthreadd can fork workers for an RT workqueue in a cgroup
+	 * which may or may not have rt_runtime allocated.  Just say no,
+	 * as attaching a global resource to a non-root group  doesn't
+	 * make any sense anyway.
+	 */
+	if (tsk == kthreadd_task)
+		return -EINVAL;
+
 #ifdef CONFIG_RT_GROUP_SCHED
 	if (!sched_rt_can_attach(cgroup_tg(cgrp), tsk))
 		return -EINVAL;

Yes, I think we need something like this. wq workers were using PF_THREAD_BOUND to prevent diddling from userland which made some unhappy. Maybe we need a flag to properly indicate "don't diddle with this thread from userland"? But, then, mainline kernel wouldn't need the current PF_THREAD_BOUND at all. Peter, Steven, what do you think?

Yes, I think we need something like this. wq workers were using PF_THREAD_BOUND to prevent diddling from userland which made some unhappy.

Maybe we need a flag to properly indicate "don't diddle with
this thread from userland"? But, then, mainline kernel wouldn't need the current PF_THREAD_BOUND at all. Peter, Steven, what do you think?

Quoted 3 lines · Tejun Heo

Yes, I think we need something like this. wq workers were using PF_THREAD_BOUND to prevent diddling from userland which made some unhappy.

But that can be properly fixed.

Quoted 3 lines

Maybe we need a flag to properly indicate "don't diddle with
this thread from userland"? But, then, mainline kernel wouldn't need the current PF_THREAD_BOUND at all. Peter, Steven, what do you think?

Strict per-cpu affinity that is needed for correctness and disallows sched_setaffinity() is something entirely different from not being allowed to put something in a cgroup.

As to not allowing to put in a cgroup thing, is there anything other than kthreadd for which we need to enforce that? So far I've mostly treated it like: root can do stupid things, this is one of them, don't do that then.

I don't know of anything other than kthreadd where moving it here, or over yonder matters one bit.

Quoted 3 lines · Mike Galbraith

I don't know of anything other than kthreadd where moving it here, or over yonder matters one bit.

Clear PF_THREAD_BOUND for watchdog or migration kthreads and change their affinity or move them into a cpuset where cpuset.cpus doesn't include the cpu they are bound to and it'll be obvious.

Quoted 3 lines

Maybe we need a flag to properly indicate "don't diddle with
this thread from userland"? But, then, mainline kernel wouldn't need the current PF_THREAD_BOUND at all. Peter, Steven, what do you think?

Strict per-cpu affinity that is needed for correctness and disallows sched_setaffinity() is something entirely different from not being allowed to put something in a cgroup.

As to not allowing to put in a cgroup thing, is there anything other than kthreadd for which we need to enforce that? So far I've mostly treated it like: root can do stupid things, this is one of them, don't do that then.

Quoted 9 lines · Mike Galbraith

Maybe the below (which seems to have been stillborn) should be done to cgroups as well. Postmortem: kthreadd is attached to a cgroup with no rt_runtime allocated, gives birth to severely handicapped kstop threads, humongous crash dump follows.

Fiddling with kthreadd is user error, but since it makes no sense to move the thing, why not just say no, and save the user's toes some needless wear and tear.

Quoted 4 lines

Quoted 4 lines

If cpusets doesn't want to let PF_THREAD_BOUND threads out, how about cpusets not letting userland scripts attach kthreadd instead?

cpusets: disallow moving kthreadd into a cpuset.

So how about this, both dirt simple and effective.

Ahem, the buildable copy..

I've been asked to add this toe saver to the trees I work on at least until something better comes along. ACK/NACK equally understandable given the infrequency of the toe shooting, and user's right to do so.

Off you go, fly or die little patchlet.

cpusets, cgroups: disallow attaching kthreadd

Allowing kthreadd to be moved to a non-root group makes no sense, it being a global resource, and needlessly leads unsuspecting users toward trouble.

1. An RT workqueue worker thread spawned in a task group with no rt_runtime allocated is not schedulable. Simple user error, but harmful to the box.

2. A worker thread which acquires PF_THREAD_BOUND can never leave a cpuset, rendering the cpuset immortal.

Save the user some unexpected trouble, just say no.

Signed-off-by Mike Galbraith <[email protected]>

---
 kernel/cpuset.c |    6 ++++--
 kernel/sched.c  |   10 ++++++++++
 2 files changed, 14 insertions(+), 2 deletions(-)

Index: linux-3.0-tip/kernel/cpuset.c
===================================================================

kernel/cpuset.c +4 -2

@@ -59,6 +59,7 @@
 #include <linux/mutex.h>
 #include <linux/workqueue.h>
 #include <linux/cgroup.h>
+#include <linux/kthread.h>
 
 /*
  * Workqueue for cpuset related tasks.

@@ -1382,9 +1383,10 @@ static int cpuset_can_attach(struct cgro
 	 * set of allowed nodes is unnecessary.  Thus, cpusets are not
 	 * applicable for such threads.  This prevents checking for success of
 	 * set_cpus_allowed_ptr() on all attached tasks before cpus_allowed may
-	 * be changed.
+	 * be changed.  We also disallow attaching kthreadd, to prevent it's
+	 * child from becoming trapped should it then acquire PF_THREAD_BOUND.
 	 */
-	if (tsk->flags & PF_THREAD_BOUND)
+	if (tsk->flags & PF_THREAD_BOUND || tsk == kthreadd_task)
 		return -EINVAL;
 
 	return 0;

Index: linux-3.0-tip/kernel/sched.c
===================================================================

kernel/sched.c +3 -0

@@ -71,6 +71,7 @@
 #include <linux/ctype.h>
 #include <linux/ftrace.h>
 #include <linux/slab.h>
+#include <linux/kthread.h>
 
 #include <asm/tlb.h>
 #include <asm/irq_regs.h>

@@ -9141,6 +9142,15 @@ cpu_cgroup_destroy(struct cgroup_subsys
 static int
 cpu_cgroup_can_attach_task(struct cgroup *cgrp, struct task_struct *tsk)
 {
+	/*
+	 * kthreadd can fork workers for an RT workqueue in a cgroup

Why special case these two, why not simply disallow moving kthreadd into _any_ cgroup what so ever and be done with it?

---

kernel/cgroup.c +3 -0

index 453100a..18eed58 100644
@@ -1824,6 +1824,9 @@ int cgroup_attach_task(struct cgroup *cgrp, struct task_struct *tsk)
 	struct cgroup *oldcgrp;
 	struct cgroupfs_root *root = cgrp->root;
 
+	if (tsk == kthreadd_task)
+		return -EINVAL;
+
 	/* Nothing to do if the task is already in that cgroup */
 	oldcgrp = task_cgroup_from_root(tsk, root);
 	if (cgrp == oldcgrp)

Quoted 2 lines · Peter Zijlstra

Why special case these two, why not simply disallow moving kthreadd into _any_ cgroup what so ever and be done with it?

These were the cases where it hurt, and cpusets don't have to be a component of a cgroup. So we'd still need the cpuset bit.

Quoted 17 lines

---

kernel/cgroup.c +3 -0

index 453100a..18eed58 100644
@@ -1824,6 +1824,9 @@ int cgroup_attach_task(struct cgroup *cgrp, struct task_struct *tsk)
 	struct cgroup *oldcgrp;
 	struct cgroupfs_root *root = cgrp->root;
 
+	if (tsk == kthreadd_task)
+		return -EINVAL;
+
 	/* Nothing to do if the task is already in that cgroup */
 	oldcgrp = task_cgroup_from_root(tsk, root);
 	if (cgrp == oldcgrp)

Quoted 7 lines · Mike Galbraith

Quoted 2 lines · Peter Zijlstra

Why special case these two, why not simply disallow moving kthreadd into _any_ cgroup what so ever and be done with it?

These were the cases where it hurt, and cpusets don't have to be a component of a cgroup. So we'd still need the cpuset bit.

but but but,, cpusetes are a cgroup thingy?!

Quoted 18 lines

Quoted 16 lines

---

kernel/cgroup.c +3 -0

index 453100a..18eed58 100644
@@ -1824,6 +1824,9 @@ int cgroup_attach_task(struct cgroup *cgrp, struct task_struct *tsk)
 	struct cgroup *oldcgrp;
 	struct cgroupfs_root *root = cgrp->root;
 
+	if (tsk == kthreadd_task)
+		return -EINVAL;
+
 	/* Nothing to do if the task is already in that cgroup */
 	oldcgrp = task_cgroup_from_root(tsk, root);
 	if (cgrp == oldcgrp)

Quoted 6 lines · Peter Zijlstra

Quoted 5 lines · Mike Galbraith

Quoted 2 lines · Peter Zijlstra

Why special case these two, why not simply disallow moving kthreadd into _any_ cgroup what so ever and be done with it?

Quoted 4 lines

Quoted 2 lines

These were the cases where it hurt, and cpusets don't have to be a component of a cgroup. So we'd still need the cpuset bit.

but but but,, cpusetes are a cgroup thingy?!

By golly, mount -t cpuset and the thing does say type cgroup. How 'bout that, learn something new every day. Dinkier is better.

From: Peter Zijlstra <[email protected]>

cgroups: disallow attaching kthreadd

Allowing kthreadd to be moved to a non-root group makes no sense, it being a global resource, and needlessly leads unsuspecting users toward trouble.

1. An RT workqueue worker thread spawned in a task group with no rt_runtime allocated is not schedulable. Simple user error, but harmful to the box.

2. A worker thread which acquires PF_THREAD_BOUND can never leave a cpuset, rendering the cpuset immortal.

Save the user some unexpected trouble, just say no.

Signed-off-by Mike Galbraith <[email protected]>

---
 kernel/cgroup.c |    9 +++++++++
 1 file changed, 9 insertions(+)

Index: linux-3.0-tip/kernel/cgroup.c
===================================================================

kernel/cgroup.c +9 -0

@@ -60,6 +60,7 @@
 #include <linux/eventfd.h>
 #include <linux/poll.h>
 #include <linux/flex_array.h> /* used in cgroup_attach_proc */
+#include <linux/kthread.h>
 
 #include <linux/atomic.h>
 

@@ -1824,6 +1825,14 @@ int cgroup_attach_task(struct cgroup *cg
 	struct cgroup *oldcgrp;
 	struct cgroupfs_root *root = cgrp->root;
 
+	/*
+	 * Workqueue threads may acquire PF_THREAD_BOUND and become
+	 * trapped in a cpuset, or RT worker may be born in a cgroup
+	 * with no rt_runtime allocated.  Just say no.
+	 */
+	if (tsk == kthreadd_task)
+		return -EINVAL;
+
 	/* Nothing to do if the task is already in that cgroup */
 	oldcgrp = task_cgroup_from_root(tsk, root);
 	if (cgrp == oldcgrp)

Quoted 4 lines · Mike Galbraith

From: Peter Zijlstra <[email protected]>

cgroups: disallow attaching kthreadd

Quoted 9 lines

Allowing kthreadd to be moved to a non-root group makes no sense, it being a global resource, and needlessly leads unsuspecting users toward trouble.

1. An RT workqueue worker thread spawned in a task group with no rt_runtime allocated is not schedulable. Simple user error, but harmful to the box.

2. A worker thread which acquires PF_THREAD_BOUND can never leave a cpuset, rendering the cpuset immortal.

Eek, this seems like complete overkill, there may be cgroups now or in the future that it would be perfectly acceptable to move kthreadd into without any negative effects. There's no reason to restrict it this broadly, that's why I thought your change to cpusets was fine and acked it. It's the perfect candidate for what the ->can_attach() pointer for a cgroup can identify is problematic for _that_ cgroup.

Quoted 4 lines

Save the user some unexpected trouble, just say no.

Signed-off-by Mike Galbraith <[email protected]>

A patch from Peter that only has your sign-off?

Oh my, I can't win.

Either of the two patchlets will do the trick, so maintainer's choice.

I can see the argument that the number of use-cases for this is fairly small, but in line with the principle of keeping the ABI as stable as possible in the absence of bugs that force a change, having the restriction in the necessary subsystems seems cleaner.

Quoted 6 lines · Paul Menage

I can see the argument that the number of use-cases for this is fairly small, but in line with the principle of keeping the ABI as stable as possible in the absence of bugs that force a change, having the restriction in the necessary subsystems seems cleaner.

Separately, an alternative fix for the cpusets case be to make it always possible to move a thread to the root cpuset, even if it's PF_THREAD_BOUND?

Eek, this seems like complete overkill, there may be cgroups now or in the future that it would be perfectly acceptable to move kthreadd into without any negative effects. There's no reason to restrict it this broadly, that's why I thought your change to cpusets was fine and acked it. It's the perfect candidate for what the ->can_attach() pointer for a cgroup can identify is problematic for _that_ cgroup.

My thinking is that kthreadd is the mother of all kernel threads and the kernel assumes it can spawn kthreads without constraints, a valid assumption IMO.

Quoted 4 lines · Peter Zijlstra

My thinking is that kthreadd is the mother of all kernel threads and the kernel assumes it can spawn kthreads without constraints, a valid assumption IMO.

Cgroups don't necessarily imply constraints,

though, you could devise a
cgroup to just do monitoring or statistics tracking for an aggregate of tasks and placing kthreadd in such a cgroup would make perfect sense because then, since children are forked in the same cgroup, you can monitor or gather statistics for all kthreads. This can be your only cgroup on the system.

Cpusets, though, does imply cpu constraints, which is why we decline PF_THREAD_BOUND threads from moving in the first place, which is the source of Mike's issue. It's can_attach() function can explicitly decline kthreadd as well since the cpu constraints of both types of threads should never be altered by either cpusets or sched_setaffinity().

Quoted 6 lines

though, you could devise a
cgroup to just do monitoring or statistics tracking for an aggregate of tasks and placing kthreadd in such a cgroup would make perfect sense because then, since children are forked in the same cgroup, you can monitor or gather statistics for all kthreads. This can be your only cgroup on the system.

I guess you could, but does it really make sense? Also, you could sort this by extending the cgroup interface to explicitly distinct between controllers and !controllers.

Save the user some unexpected trouble, just say no.

Signed-off-by Mike Galbraith <[email protected]>

---
 kernel/cpuset.c |    6 ++++--
 kernel/sched.c  |   10 ++++++++++

 2 files changed, 14 insertions(+), 2 deletions(-)

Index: linux-3.0-tip/kernel/cpuset.c
===================================================================

kernel/cpuset.c +4 -2

@@ -59,6 +59,7 @@
  #include <linux/mutex.h>
  #include <linux/workqueue.h>
  #include <linux/cgroup.h>
+#include <linux/kthread.h>
 
  /*
  * Workqueue for cpuset related tasks.

@@ -1382,9 +1383,10 @@ static int cpuset_can_attach(struct cgro
         * set of allowed nodes is unnecessary.  Thus, cpusets are not
         * applicable for such threads.  This prevents checking for success of
         * set_cpus_allowed_ptr() on all attached tasks before cpus_allowed may
-        * be changed.
+        * be changed.  We also disallow attaching kthreadd, to prevent it's
+        * child from becoming trapped should it then acquire PF_THREAD_BOUND.
         */
-       if (tsk->flags & PF_THREAD_BOUND)
+       if (tsk->flags & PF_THREAD_BOUND || tsk == kthreadd_task)
                return -EINVAL;
 
        return 0;

Index: linux-3.0-tip/kernel/sched.c
===================================================================

kernel/sched.c +1 -0

@@ -71,6 +71,7 @@
  #include <linux/ctype.h>
  #include <linux/ftrace.h>
  #include <linux/slab.h>
+#include <linux/kthread.h>
 
  #include <asm/tlb.h>
  #include <asm/irq_regs.h>

@@ -9141,6 +9142,15 @@ cpu_cgroup_destroy(struct cgroup_subsys

 static int
 cpu_cgroup_can_attach_task(struct cgroup *cgrp, struct task_struct *tsk) {
+       /*
+        * kthreadd can fork workers for an RT workqueue in a cgroup
+        * which may or may not have rt_runtime allocated.  Just say no,
+        * as attaching a global resource to a non-root group  doesn't
+        * make any sense anyway.
+        */
+       if (tsk == kthreadd_task)
+               return -EINVAL;
+
 #ifdef CONFIG_RT_GROUP_SCHED
       if (!sched_rt_can_attach(cgroup_tg(cgrp), tsk))
               return -EINVAL;

Quoted 4 lines · Mike Galbraith

Save the user some unexpected trouble, just say no.

Signed-off-by Mike Galbraith <[email protected]>

Acked-by Paul Menage <[email protected]>

Thanks. Ok, seems it is decided that this is the best way to deal with annoying corner-case. For convenience, patch with acquired acks below.

I really think that if we want to restrain userspace from doing something stupid we might as well do something that makes sense,

Quoted 3 lines · Mike Galbraith

Thanks. Ok, seems it is decided that this is the best way to deal with annoying corner-case. For convenience, patch with acquired acks below.

Ah, but I'm not rolling over that easily ;-)

cpusets, cgroups: disallow attaching kthreadd

Allowing kthreadd to be moved to a non-root group makes no sense, it being a global resource, and needlessly leads unsuspecting users toward trouble.

1. An RT workqueue worker thread spawned in a task group with no rt_runtime allocated is not schedulable. Simple user error, but harmful to the box.

2. A worker thread which acquires PF_THREAD_BOUND can never leave a cpuset, rendering the cpuset immortal.

Save the user some unexpected trouble, just say no.

Signed-off-by Mike Galbraith <[email protected]>

Acked-by David Rientjes <[email protected]>

Acked-by Paul Menage <[email protected]>

---
 kernel/cpuset.c |    6 ++++--
 kernel/sched.c  |   10 ++++++++++
 2 files changed, 14 insertions(+), 2 deletions(-)

Index: linux-3.0-tip/kernel/cpuset.c
===================================================================

kernel/cpuset.c +4 -2

@@ -59,6 +59,7 @@
 #include <linux/mutex.h>
 #include <linux/workqueue.h>
 #include <linux/cgroup.h>
+#include <linux/kthread.h>
 
 /*
  * Workqueue for cpuset related tasks.

@@ -1382,9 +1383,10 @@ static int cpuset_can_attach(struct cgro
 	 * set of allowed nodes is unnecessary.  Thus, cpusets are not
 	 * applicable for such threads.  This prevents checking for success of
 	 * set_cpus_allowed_ptr() on all attached tasks before cpus_allowed may
-	 * be changed.
+	 * be changed.  We also disallow attaching kthreadd, to prevent it's
+	 * child from becoming trapped should it then acquire PF_THREAD_BOUND.
 	 */
-	if (tsk->flags & PF_THREAD_BOUND)
+	if (tsk->flags & PF_THREAD_BOUND || tsk == kthreadd_task)
 		return -EINVAL;
 
 	return 0;

Index: linux-3.0-tip/kernel/sched.c
===================================================================

kernel/sched.c +10 -0

@@ -71,6 +71,7 @@
 #include <linux/ctype.h>
 #include <linux/ftrace.h>
 #include <linux/slab.h>
+#include <linux/kthread.h>
 
 #include <asm/tlb.h>
 #include <asm/irq_regs.h>

@@ -9141,6 +9142,15 @@ cpu_cgroup_destroy(struct cgroup_subsys
 static int
 cpu_cgroup_can_attach_task(struct cgroup *cgrp, struct task_struct *tsk)
 {
+	/*
+	 * kthreadd can fork workers for an RT workqueue in a cgroup
+	 * which may or may not have rt_runtime allocated.  Just say no,
+	 * as attaching a global resource to a non-root group  doesn't
+	 * make any sense anyway.
+	 */
+	if (tsk == kthreadd_task)
+		return -EINVAL;
+
 #ifdef CONFIG_RT_GROUP_SCHED
 	if (!sched_rt_can_attach(cgroup_tg(cgrp), tsk))
 		return -EINVAL;

Quoted 13 lines · Mike Galbraith

cpusets, cgroups: disallow attaching kthreadd

Allowing kthreadd to be moved to a non-root group makes no sense, it being a global resource, and needlessly leads unsuspecting users toward trouble.

1. An RT workqueue worker thread spawned in a task group with no rt_runtime allocated is not schedulable. Simple user error, but harmful to the box.

2. A worker thread which acquires PF_THREAD_BOUND can never leave a cpuset, rendering the cpuset immortal.

Save the user some unexpected trouble, just say no.

Quoted 4 lines

Signed-off-by Mike Galbraith <[email protected]>

Acked-by David Rientjes <[email protected]>

Acked-by Paul Menage <[email protected]>

Let's add Andrew to the cc so we can get it in -mm, I haven't seen it hit linux-next yet.

Quoted 58 lines

---
 kernel/cpuset.c |    6 ++++--
 kernel/sched.c  |   10 ++++++++++
 2 files changed, 14 insertions(+), 2 deletions(-)

Index: linux-3.0-tip/kernel/cpuset.c
===================================================================

kernel/cpuset.c +4 -2

@@ -59,6 +59,7 @@
 #include <linux/mutex.h>
 #include <linux/workqueue.h>
 #include <linux/cgroup.h>
+#include <linux/kthread.h>
 
 /*
  * Workqueue for cpuset related tasks.

@@ -1382,9 +1383,10 @@ static int cpuset_can_attach(struct cgro
 	 * set of allowed nodes is unnecessary.  Thus, cpusets are not
 	 * applicable for such threads.  This prevents checking for success of
 	 * set_cpus_allowed_ptr() on all attached tasks before cpus_allowed may
-	 * be changed.
+	 * be changed.  We also disallow attaching kthreadd, to prevent it's
+	 * child from becoming trapped should it then acquire PF_THREAD_BOUND.
 	 */
-	if (tsk->flags & PF_THREAD_BOUND)
+	if (tsk->flags & PF_THREAD_BOUND || tsk == kthreadd_task)
 		return -EINVAL;
 
 	return 0;

Index: linux-3.0-tip/kernel/sched.c
===================================================================

kernel/sched.c +10 -0

@@ -71,6 +71,7 @@
 #include <linux/ctype.h>
 #include <linux/ftrace.h>
 #include <linux/slab.h>
+#include <linux/kthread.h>
 
 #include <asm/tlb.h>
 #include <asm/irq_regs.h>

@@ -9141,6 +9142,15 @@ cpu_cgroup_destroy(struct cgroup_subsys
 static int
 cpu_cgroup_can_attach_task(struct cgroup *cgrp, struct task_struct *tsk)
 {
+	/*
+	 * kthreadd can fork workers for an RT workqueue in a cgroup
+	 * which may or may not have rt_runtime allocated.  Just say no,
+	 * as attaching a global resource to a non-root group  doesn't
+	 * make any sense anyway.
+	 */
+	if (tsk == kthreadd_task)
+		return -EINVAL;
+
 #ifdef CONFIG_RT_GROUP_SCHED
 	if (!sched_rt_can_attach(cgroup_tg(cgrp), tsk))
 		return -EINVAL;

Quoted 20 lines · David Rientjes

Quoted 17 lines · Mike Galbraith

cpusets, cgroups: disallow attaching kthreadd

Allowing kthreadd to be moved to a non-root group makes no sense, it being a global resource, and needlessly leads unsuspecting users toward trouble.

1. An RT workqueue worker thread spawned in a task group with no rt_runtime allocated is not schedulable. Simple user error, but harmful to the box.

2. A worker thread which acquires PF_THREAD_BOUND can never leave a cpuset, rendering the cpuset immortal.

Save the user some unexpected trouble, just say no.

Signed-off-by Mike Galbraith <[email protected]>

Acked-by David Rientjes <[email protected]>

Acked-by Paul Menage <[email protected]>

Quoted 3 lines

Let's add Andrew to the cc so we can get it in -mm, I haven't seen it hit linux-next yet.

Ping? Still missing from -mm and linux-next.

Quoted 58 lines

Quoted 58 lines

---
 kernel/cpuset.c |    6 ++++--
 kernel/sched.c  |   10 ++++++++++
 2 files changed, 14 insertions(+), 2 deletions(-)

Index: linux-3.0-tip/kernel/cpuset.c
===================================================================

kernel/cpuset.c +4 -2

@@ -59,6 +59,7 @@
 #include <linux/mutex.h>
 #include <linux/workqueue.h>
 #include <linux/cgroup.h>
+#include <linux/kthread.h>
 
 /*
  * Workqueue for cpuset related tasks.

@@ -1382,9 +1383,10 @@ static int cpuset_can_attach(struct cgro
 	 * set of allowed nodes is unnecessary.  Thus, cpusets are not
 	 * applicable for such threads.  This prevents checking for success of
 	 * set_cpus_allowed_ptr() on all attached tasks before cpus_allowed may
-	 * be changed.
+	 * be changed.  We also disallow attaching kthreadd, to prevent it's
+	 * child from becoming trapped should it then acquire PF_THREAD_BOUND.
 	 */
-	if (tsk->flags & PF_THREAD_BOUND)
+	if (tsk->flags & PF_THREAD_BOUND || tsk == kthreadd_task)
 		return -EINVAL;
 
 	return 0;

Index: linux-3.0-tip/kernel/sched.c
===================================================================

kernel/sched.c +10 -0

@@ -71,6 +71,7 @@
 #include <linux/ctype.h>
 #include <linux/ftrace.h>
 #include <linux/slab.h>
+#include <linux/kthread.h>
 
 #include <asm/tlb.h>
 #include <asm/irq_regs.h>

@@ -9141,6 +9142,15 @@ cpu_cgroup_destroy(struct cgroup_subsys
 static int
 cpu_cgroup_can_attach_task(struct cgroup *cgrp, struct task_struct *tsk)
 {
+	/*
+	 * kthreadd can fork workers for an RT workqueue in a cgroup
+	 * which may or may not have rt_runtime allocated.  Just say no,
+	 * as attaching a global resource to a non-root group  doesn't
+	 * make any sense anyway.
+	 */
+	if (tsk == kthreadd_task)
+		return -EINVAL;
+
 #ifdef CONFIG_RT_GROUP_SCHED
 	if (!sched_rt_can_attach(cgroup_tg(cgrp), tsk))
 		return -EINVAL;

Quoted 22 lines · David Rientjes

Quoted 20 lines · David Rientjes

Quoted 17 lines · Mike Galbraith

cpusets, cgroups: disallow attaching kthreadd

Allowing kthreadd to be moved to a non-root group makes no sense, it being a global resource, and needlessly leads unsuspecting users toward trouble.

1. An RT workqueue worker thread spawned in a task group with no rt_runtime allocated is not schedulable. Simple user error, but harmful to the box.

2. A worker thread which acquires PF_THREAD_BOUND can never leave a cpuset, rendering the cpuset immortal.

Save the user some unexpected trouble, just say no.

Signed-off-by Mike Galbraith <[email protected]>

Acked-by David Rientjes <[email protected]>

Acked-by Paul Menage <[email protected]>

Quoted 6 lines

Quoted 3 lines

Let's add Andrew to the cc so we can get it in -mm, I haven't seen it hit linux-next yet.

Ping? Still missing from -mm and linux-next.

Ping #2?

Quoted 2 lines

Ping #2?

Why am I being pinged about scheduler patches? My sole contribution to this one is to point out that "its"->possessive and "it's"->"it is".

Also, Peter has said

: I really think that if we want to restrain userspace from doing : something stupid we might as well do something that makes sense, and : that is mandate kthreadd stays in the root group at all times for : everybody.

which appears to be what the patch already did, so I'm confused again.

It's time for a fresh resend, IMO.

Would
you like the change separated into kernel/cpuset.c and kernel/sched.c portions each referring to each other?

Mike, would you mind resending the patch for the fourth or fifth time? If not, I'll rebase it.

Mike, would you mind resending the patch for the fourth or fifth time? If not, I'll rebase it.

Door #1 with speeling correction.

From: Mike Galbraith <[email protected]>

cpusets, cgroups: disallow attaching kthreadd

Allowing kthreadd to be moved to a non-root group makes no sense, it being a global resource, and needlessly leads unsuspecting users toward trouble.

1. An RT workqueue worker thread spawned in a task group with no rt_runtime allocated is not schedulable. Simple user error, but harmful to the box.

2. A worker thread which acquires PF_THREAD_BOUND can never leave a cpuset, rendering the cpuset immortal.

Save the user some unexpected trouble, just say no.

Signed-off-by Mike Galbraith <[email protected]>

Acked-by David Rientjes <[email protected]>

Acked-by Paul Menage <[email protected]>

---
 kernel/cpuset.c     |    6 ++++--
 kernel/sched/core.c |   10 ++++++++++
 2 files changed, 14 insertions(+), 2 deletions(-)

Index: linux-3.0-tip/kernel/cpuset.c
===================================================================

kernel/cpuset.c +4 -2

@@ -59,6 +59,7 @@
 #include <linux/mutex.h>
 #include <linux/workqueue.h>
 #include <linux/cgroup.h>
+#include <linux/kthread.h>
 
 /*
  * Workqueue for cpuset related tasks.

@@ -1385,9 +1386,10 @@ static int cpuset_can_attach(struct cgro
 	 * set of allowed nodes is unnecessary.  Thus, cpusets are not
 	 * applicable for such threads.  This prevents checking for success of
 	 * set_cpus_allowed_ptr() on all attached tasks before cpus_allowed may
-	 * be changed.
+	 * be changed.  We also disallow attaching kthreadd, to prevent its
+	 * child from becoming trapped should it then acquire PF_THREAD_BOUND.
 	 */
-	if (tsk->flags & PF_THREAD_BOUND)
+	if (tsk->flags & PF_THREAD_BOUND || tsk == kthreadd_task)
 		return -EINVAL;
 
 	return 0;

Index: linux-3.0-tip/kernel/sched/core.c
===================================================================

kernel/sched/core.c +10 -0

@@ -71,6 +71,7 @@
 #include <linux/ftrace.h>
 #include <linux/slab.h>
 #include <linux/init_task.h>
+#include <linux/kthread.h>
 
 #include <asm/tlb.h>
 #include <asm/irq_regs.h>

@@ -7461,6 +7462,15 @@ cpu_cgroup_destroy(struct cgroup_subsys
 static int
 cpu_cgroup_can_attach_task(struct cgroup *cgrp, struct task_struct *tsk)
 {
+	/*
+	 * kthreadd can fork workers for an RT workqueue in a cgroup
+	 * which may or may not have rt_runtime allocated.  Just say no,
+	 * as attaching a global resource to a non-root group  doesn't
+	 * make any sense anyway.
+	 */
+	if (tsk == kthreadd_task)
+		return -EINVAL;
+
 #ifdef CONFIG_RT_GROUP_SCHED
 	if (!sched_rt_can_attach(cgroup_tg(cgrp), tsk))
 		return -EINVAL;

Quoted 15 lines · Mike Galbraith

Door #1 with speeling correction.

From: Mike Galbraith <[email protected]>

cpusets, cgroups: disallow attaching kthreadd

Allowing kthreadd to be moved to a non-root group makes no sense, it being a global resource, and needlessly leads unsuspecting users toward trouble.

1. An RT workqueue worker thread spawned in a task group with no rt_runtime allocated is not schedulable. Simple user error, but harmful to the box.

2. A worker thread which acquires PF_THREAD_BOUND can never leave a cpuset, rendering the cpuset immortal.

Quoted 5 lines

Save the user some unexpected trouble, just say no.

Signed-off-by Mike Galbraith <[email protected]>

Acked-by David Rientjes <[email protected]>

Acked-by Paul Menage <[email protected]>

Yes, this looks good. Andrew could you apply this?

diff -puN kernel/cpuset.c~cpusets-cgroups-disallow-attaching-kthreadd kernel/cpuset.c

kernel/cpuset.c renamed from kernel/cpuset.c~cpusets-cgroups-disallow-attaching-kthreadd +5 -2

@@ -59,6 +59,7 @@
 #include <linux/mutex.h>
 #include <linux/workqueue.h>
 #include <linux/cgroup.h>
+#include <linux/kthread.h>
 
 /*
  * Workqueue for cpuset related tasks.

@@ -1417,9 +1418,11 @@ static int cpuset_can_attach(struct cgro
 		 * unnecessary.  Thus, cpusets are not applicable for such
 		 * threads.  This prevents checking for success of
 		 * set_cpus_allowed_ptr() on all attached tasks before
-		 * cpus_allowed may be changed.
+		 * cpus_allowed may be changed.  We also disallow attaching
+		 * kthreadd, to prevent its child from becoming trapped should
+		 * it then acquire PF_THREAD_BOUND.
 		 */
-		if (task->flags & PF_THREAD_BOUND)
+		if (tsk->flags & PF_THREAD_BOUND || tsk == kthreadd_task)
 			return -EINVAL;
 		if ((ret = security_task_setscheduler(task)))
 			return ret;

diff -puN kernel/sched/core.c~cpusets-cgroups-disallow-attaching-kthreadd kernel/sched/core.c

kernel/sched/core.c renamed from kernel/sched/core.c~cpusets-cgroups-disallow-attaching-kthreadd +2 -0

@@ -71,6 +71,7 @@
 #include <linux/ftrace.h>
 #include <linux/slab.h>
 #include <linux/init_task.h>
+#include <linux/kthread.h>
 
 #include <asm/tlb.h>
 #include <asm/irq_regs.h>

@@ -7535,6 +7536,14 @@ static int cpu_cgroup_can_attach(struct 
 	struct task_struct *task;
 
 	cgroup_taskset_for_each(task, cgrp, tset) {
+		/*

cpusets, cgroups: disallow attaching kthreadd

Allowing kthreadd to be moved to a non-root group makes no sense, it being a global resource, and needlessly leads unsuspecting users toward trouble.

1. An RT workqueue worker thread spawned in a task group with no rt_runtime allocated is not schedulable. Simple user error, but harmful to the box.

2. A worker thread which acquires PF_THREAD_BOUND can never leave a cpuset, rendering the cpuset immortal.

Save the user some unexpected trouble, just say no.

Quoted 11 lines · On Wed, 07 Dec 2011 05:36:57 +0100 Mike Galbraith <[email protected]> wrote:

cpusets, cgroups: disallow attaching kthreadd

Allowing kthreadd to be moved to a non-root group makes no sense, it being a global resource, and needlessly leads unsuspecting users toward trouble.

1. An RT workqueue worker thread spawned in a task group with no rt_runtime allocated is not schedulable. Simple user error, but harmful to the box.

2. A worker thread which acquires PF_THREAD_BOUND can never leave a cpuset, rendering the cpuset immortal.

Quoted 1 line

Save the user some unexpected trouble, just say no.

Someone's been screwing around in linux-next during the merge window. afacit some patch which was previously there has magically disappeared. That killed your patch - the original version of the kernel/sched/core.c chagne applies to the new linux-next but the kernel/cpuset.c part is all wrecked.

I can't get to mmotm to see what's there, but fresh pulled linux-next has it as 904655b9, and looked ok. (?) The only thing I can think to do is post it as just plugged into fresh pulled master and hope that helps turn little floundering guppy right side up again.

Quoted 2 lines

Mike, would you mind resending the patch for the fourth or fifth time? If not, I'll rebase it.

Sure, below are the two candidates. I like Peter's idea better (door #2), "Keep yer grubby mitts offa _my_ Mom" is a natural reaction ;-)

Door #2

From: Mike Galbraith <[email protected]>

cgroups: disallow attaching kthreadd

Allowing kthreadd to be moved to a non-root group makes no sense, it being a global resource, and needlessly leads unsuspecting users toward trouble.

1. An RT workqueue worker thread spawned in a task group with no rt_runtime allocated is not schedulable. Simple user error, but harmful to the box.

2. A worker thread which acquires PF_THREAD_BOUND can never leave a cpuset, rendering the cpuset immortal.

Save the user some unexpected trouble, just say no.

Signed-off-by Mike Galbraith <[email protected]>

---
 kernel/cgroup.c |    9 +++++++++
 1 file changed, 9 insertions(+)

Index: linux-3.0-tip/kernel/cgroup.c
===================================================================

kernel/cgroup.c +9 -0

@@ -60,6 +60,7 @@
 #include <linux/eventfd.h>
 #include <linux/poll.h>
 #include <linux/flex_array.h> /* used in cgroup_attach_proc */
+#include <linux/kthread.h>
 
 #include <linux/atomic.h>
 

@@ -1824,6 +1825,14 @@ int cgroup_attach_task(struct cgroup *cg
 	struct cgroup *oldcgrp;
 	struct cgroupfs_root *root = cgrp->root;
 
+	/*
+	 * Workqueue threads may acquire PF_THREAD_BOUND and become
+	 * trapped in a cpuset, or RT worker may be born in a cgroup
+	 * with no rt_runtime allocated.  Just say no.
+	 */
+	if (tsk == kthreadd_task)
+		return -EINVAL;
+
 	/* Nothing to do if the task is already in that cgroup */
 	oldcgrp = task_cgroup_from_root(tsk, root);
 	if (cgrp == oldcgrp)