From: Oleg Nesterov <oleg@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>, Chris Mason <clm@fb.com>,
linux-kernel@vger.kernel.org, kernel-team@fb.com,
Li Zefan <lizefan@huawei.com>,
Johannes Weiner <hannes@cmpxchg.org>,
cgroups@vger.kernel.org
Subject: Re: [PATCH 2/2] kthread, cgroup: close race window where new kthreads can be migrated to non-root cgroups
Date: Thu, 16 Mar 2017 16:39:26 +0100 [thread overview]
Message-ID: <20170316153925.GA26391@redhat.com> (raw)
In-Reply-To: <20170316150233.GB24478@redhat.com>
On 03/16, Oleg Nesterov wrote:
>
> On 03/15, Tejun Heo wrote:
> >
> > --- a/kernel/cgroup/cgroup.c
> > +++ b/kernel/cgroup/cgroup.c
> > @@ -2425,11 +2425,13 @@ ssize_t __cgroup_procs_write(struct kern
> > tsk = tsk->group_leader;
> >
> > /*
> > - * Workqueue threads may acquire PF_NO_SETAFFINITY and become
> > - * trapped in a cpuset, or RT worker may be born in a cgroup
> > - * with no rt_runtime allocated. Just say no.
> > + * kthreads may acquire PF_NO_SETAFFINITY during initialization.
> > + * If userland migrates such kthread to a non-root cgroup, it can
> > + * become trapped in a cpuset, or RT kthread may be born in a
> > + * cgroup with no rt_runtime allocated. Just say no.
> > */
> > - if (tsk == kthreadd_task || (tsk->flags & PF_NO_SETAFFINITY)) {
> > + if (tsk == kthreadd_task || (tsk->flags & PF_NO_SETAFFINITY) ||
> > + ((tsk->flags & PF_KTHREAD) && !kthread_initialized(tsk))) {
> > ret = -EINVAL;
>
> ...
>
> > +bool kthread_initialized(struct task_struct *k)
> > +{
> > + struct kthread *kthread = to_kthread(k);
> > +
> > + return kthread && test_bit(KTHREAD_INITIALIZED, &kthread->flags);
> > +}
>
> Not sure I understand...
>
> With this patch you can no longer migrate a kernel thread created by
> kernel_thread() ? Note that to_kthread() is NULL unless it was created
> by kthread_create().
Either way, I am wondering if we can do something really trivial like
the patch below. This way we can also remove the "tsk == kthreadd_task"
check, and we do not need the barriers.
Oleg.
--- x/kernel/kthread.c
+++ x/kernel/kthread.c
@@ -226,6 +226,7 @@
ret = -EINTR;
if (!test_bit(KTHREAD_SHOULD_STOP, &self->flags)) {
__kthread_parkme(self);
+ current->flags &= ~PF_IDONTLIKECGROUPS;
ret = threadfn(data);
}
do_exit(ret);
@@ -537,7 +538,7 @@
set_cpus_allowed_ptr(tsk, cpu_all_mask);
set_mems_allowed(node_states[N_MEMORY]);
- current->flags |= PF_NOFREEZE;
+ current->flags |= (PF_NOFREEZE | PF_IDONTLIKECGROUPS);
for (;;) {
set_current_state(TASK_INTERRUPTIBLE);
--- x/kernel/cgroup/cgroup.c
+++ x/kernel/cgroup/cgroup.c
@@ -2429,7 +2429,7 @@
* 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 || (tsk->flags & PF_NO_SETAFFINITY)) {
+ if (tsk->flags & (PF_NO_SETAFFINITY | PF_IDONTLIKECGROUPS)) {
ret = -EINVAL;
goto out_unlock_rcu;
}
next prev parent reply other threads:[~2017-03-16 15:41 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-15 23:18 [PATCH 1/2] kthread: add barriers to set_kthread_struct() and to_kthread() Tejun Heo
2017-03-15 23:19 ` [PATCH 2/2] kthread, cgroup: close race window where new kthreads can be migrated to non-root cgroups Tejun Heo
2017-03-16 15:02 ` Oleg Nesterov
2017-03-16 15:39 ` Oleg Nesterov [this message]
2017-03-16 16:07 ` Tejun Heo
2017-03-16 16:31 ` Oleg Nesterov
2017-03-16 17:41 ` Tejun Heo
2017-03-16 16:05 ` Tejun Heo
2017-03-16 16:17 ` Oleg Nesterov
2017-03-16 17:03 ` Tejun Heo
2017-03-16 20:54 ` [PATCH v2] cgroup, kthread: " Tejun Heo
2017-03-17 13:50 ` Oleg Nesterov
2017-03-17 14:44 ` Tejun Heo
2017-03-16 14:54 ` [PATCH 1/2] kthread: add barriers to set_kthread_struct() and to_kthread() Oleg Nesterov
2017-03-16 15:33 ` Tejun Heo
2017-03-16 15:38 ` Tejun Heo
2017-03-16 15:46 ` Oleg Nesterov
2017-03-16 15:55 ` Peter Zijlstra
2017-03-16 16:09 ` Tejun Heo
2017-03-16 16:14 ` Peter Zijlstra
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=20170316153925.GA26391@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=clm@fb.com \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox