From: Mike Galbraith <efault@gmx.de>
To: David Rientjes <rientjes@google.com>
Cc: Tejun Heo <htejun@gmail.com>, Li Zefan <lizf@cn.fujitsu.com>,
LKML <linux-kernel@vger.kernel.org>,
Paul Menage <paul@paulmenage.org>
Subject: Re: [patch] cpusets: allow PF_THREAD_BOUND kworkers to escape from a cpuset
Date: Fri, 23 Sep 2011 12:53:24 +0200 [thread overview]
Message-ID: <1316775204.7562.9.camel@marge.simson.net> (raw)
In-Reply-To: <1316770936.6641.11.camel@marge.simson.net>
On Fri, 2011-09-23 at 11:42 +0200, Mike Galbraith wrote:
> On Fri, 2011-09-23 at 02:12 -0700, David Rientjes wrote:
> > On Fri, 23 Sep 2011, Mike Galbraith wrote:
> >
> > > 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..
>
> > 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.
>
> > 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.
So unless there's some reason kworker threads should worry about their
birthplace, seems to me we should just let the cpuset interface handle
the oddball case.
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 <efault@gmx.de>
Acked-by: Li Zefan <lizf@cn.fujitsu.com>
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 10131fd..3769f9e 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -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);
+ }
cpuset_change_task_nodemask(tsk, &cpuset_attach_nodemask_to);
cpuset_update_task_spread_flag(cs, tsk);
next prev parent reply other threads:[~2011-09-23 10:53 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-23 6:21 [patch] cpusets: allow PF_THREAD_BOUND kworkers to escape from a cpuset Mike Galbraith
2011-09-23 7:00 ` Li Zefan
2011-09-23 7:19 ` Mike Galbraith
2011-09-23 9:12 ` David Rientjes
2011-09-23 9:42 ` Mike Galbraith
2011-09-23 10:53 ` Mike Galbraith [this message]
2011-09-23 13:27 ` David Rientjes
2011-09-23 14:33 ` Mike Galbraith
2011-09-23 18:16 ` Mike Galbraith
2011-09-23 20:20 ` David Rientjes
2011-09-24 3:21 ` Tejun Heo
2011-10-10 5:34 ` Mike Galbraith
2011-10-10 8:03 ` [patch] cpusets, cgroups: disallow attaching kthreadd Mike Galbraith
2011-10-10 16:43 ` Tejun Heo
2011-10-11 2:31 ` Mike Galbraith
2011-10-11 14:08 ` Peter Zijlstra
2011-10-11 16:57 ` Mike Galbraith
2011-10-12 1:22 ` David Rientjes
2011-10-12 1:45 ` Mike Galbraith
2011-10-12 1:20 ` David Rientjes
2011-10-18 8:10 ` patch] " Mike Galbraith
2011-10-18 8:16 ` David Rientjes
2011-10-18 8:42 ` Peter Zijlstra
2011-10-18 8:47 ` Mike Galbraith
2011-10-18 9:06 ` Peter Zijlstra
2011-10-18 9:23 ` Mike Galbraith
2011-10-18 10:11 ` Mike Galbraith
2011-10-18 20:38 ` David Rientjes
2011-10-19 4:00 ` Mike Galbraith
2011-10-19 4:53 ` Paul Menage
2011-10-19 4:56 ` Paul Menage
2011-10-19 5:28 ` Mike Galbraith
2011-10-19 7:50 ` Peter Zijlstra
2011-10-19 19:47 ` David Rientjes
2011-10-20 10:32 ` Peter Zijlstra
2011-10-20 21:24 ` David Rientjes
2011-10-19 4:57 ` Paul Menage
2011-10-19 5:24 ` [patch-final] " Mike Galbraith
2011-10-19 7:54 ` Peter Zijlstra
2011-10-19 8:00 ` Paul Menage
2011-10-19 8:21 ` Mike Galbraith
2011-10-26 20:27 ` David Rientjes
2011-11-10 20:51 ` David Rientjes
2011-12-06 20:13 ` David Rientjes
2011-12-06 22:47 ` Andrew Morton
2011-12-06 23:53 ` David Rientjes
2011-12-07 0:05 ` Andrew Morton
2011-12-07 3:18 ` [resubmit] " Mike Galbraith
2011-12-07 4:36 ` Mike Galbraith
2011-12-07 22:03 ` David Rientjes
2011-12-14 20:16 ` Andrew Morton
2011-12-15 2:50 ` David Rientjes
2012-01-06 22:06 ` Andrew Morton
2012-01-07 6:34 ` Mike Galbraith
2012-01-07 7:59 ` Andrew Morton
2011-12-07 22:01 ` David Rientjes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1316775204.7562.9.camel@marge.simson.net \
--to=efault@gmx.de \
--cc=htejun@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=paul@paulmenage.org \
--cc=rientjes@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.