All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Li Zefan <lizefan@huawei.com>
Cc: Tejun Heo <tj@kernel.org>, anjana vk <anjanvk12@gmail.com>,
	cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
	eunki_kim@samsung.com
Subject: cgroup_attach_task && while_each_thread (Was: cgroup attach task - slogging cpu)
Date: Wed, 9 Oct 2013 18:54:48 +0200	[thread overview]
Message-ID: <20131009165448.GA22437@redhat.com> (raw)
In-Reply-To: <20131009140551.GA15849@redhat.com>

And I am starting to think that this change should also fix the
while_each_thread() problems in this particular case.

In generak the code like

	rcu_read_lock();
	task = find_get_task(...);
	rcu_read_unlock();

	rcu_read_lock();
	t = task;
	do {
		...
	} while_each_thread (task, t);
	rcu_read_unlock();

is wrong even if while_each_thread() was correct (and we have a lot
of examples of this pattern). A GP can pass before the 2nd rcu-lock,
and we simply can't trust ->thread_group.next.

But I didn't notice that cgroup_attach_task(tsk, threadgroup) can only
be called with threadgroup == T when a) tsk is ->group_leader and b)
we hold threadgroup_lock() which blocks de_thread(). IOW, in this case
"tsk" can't be removed from ->thread_group list before other threads.

If next_thread() sees thread_group.next != leader, we know that the
that .next thread didn't do __unhash_process() yet, and since we
know that in this case "leader" didn't do this too we are safe.

In short: __unhash_process(leader) (in this) case can never change
->thread_group.next of another thread, because leader->thread_group
should be already list_empty().

On 10/09, Oleg Nesterov wrote:
>
> On 10/09, Oleg Nesterov wrote:
> >
> > On 10/09, Li Zefan wrote:
> > >
> > > Anjana, could you revise the patch and send it out with proper changelog
> > > and Signed-off-by? And please add "Cc: <stable@vger.kernel.org> # 3.9+"
> >
> > Yes, Anjana, please!
>
> Please note also that the PF_EXITING check has the same problem, it also
> needs "goto next".
>
> > > > check in the main loop. So Anjana was right (sorry again!), and we
> > > > should probably do
> > > >
> > > > 		ent.cgrp = task_cgroup_from_root(...);
> > > > 		if (ent.cgrp != cgrp) {
> > > > 			retval = flex_array_put(...);
> > > > 			...
> > > > 		}
> > > >
> > > > 		if (!threadgroup)
> > > > 			break;
> > > >
> > >
> > > Or
> > >
> > > do {
> > > 	...
> > > 	if (ent.cgrp == cgrp)
> > > 		goto next;
> >
> > Or this, agreed.
> >
> > > > Or I am wrong again?
> > >
> > > No, you are not! :)
> >
> > Thanks ;)
> >
> > Oleg.


WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	anjana vk <anjanvk12-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	eunki_kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org
Subject: cgroup_attach_task && while_each_thread (Was: cgroup attach task - slogging cpu)
Date: Wed, 9 Oct 2013 18:54:48 +0200	[thread overview]
Message-ID: <20131009165448.GA22437@redhat.com> (raw)
In-Reply-To: <20131009140551.GA15849-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

And I am starting to think that this change should also fix the
while_each_thread() problems in this particular case.

In generak the code like

	rcu_read_lock();
	task = find_get_task(...);
	rcu_read_unlock();

	rcu_read_lock();
	t = task;
	do {
		...
	} while_each_thread (task, t);
	rcu_read_unlock();

is wrong even if while_each_thread() was correct (and we have a lot
of examples of this pattern). A GP can pass before the 2nd rcu-lock,
and we simply can't trust ->thread_group.next.

But I didn't notice that cgroup_attach_task(tsk, threadgroup) can only
be called with threadgroup == T when a) tsk is ->group_leader and b)
we hold threadgroup_lock() which blocks de_thread(). IOW, in this case
"tsk" can't be removed from ->thread_group list before other threads.

If next_thread() sees thread_group.next != leader, we know that the
that .next thread didn't do __unhash_process() yet, and since we
know that in this case "leader" didn't do this too we are safe.

In short: __unhash_process(leader) (in this) case can never change
->thread_group.next of another thread, because leader->thread_group
should be already list_empty().

On 10/09, Oleg Nesterov wrote:
>
> On 10/09, Oleg Nesterov wrote:
> >
> > On 10/09, Li Zefan wrote:
> > >
> > > Anjana, could you revise the patch and send it out with proper changelog
> > > and Signed-off-by? And please add "Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # 3.9+"
> >
> > Yes, Anjana, please!
>
> Please note also that the PF_EXITING check has the same problem, it also
> needs "goto next".
>
> > > > check in the main loop. So Anjana was right (sorry again!), and we
> > > > should probably do
> > > >
> > > > 		ent.cgrp = task_cgroup_from_root(...);
> > > > 		if (ent.cgrp != cgrp) {
> > > > 			retval = flex_array_put(...);
> > > > 			...
> > > > 		}
> > > >
> > > > 		if (!threadgroup)
> > > > 			break;
> > > >
> > >
> > > Or
> > >
> > > do {
> > > 	...
> > > 	if (ent.cgrp == cgrp)
> > > 		goto next;
> >
> > Or this, agreed.
> >
> > > > Or I am wrong again?
> > >
> > > No, you are not! :)
> >
> > Thanks ;)
> >
> > Oleg.

  reply	other threads:[~2013-10-09 18:20 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-04  5:25 cgroup attach task - slogging cpu anjana vk
     [not found] ` <CALPf4Tz+Gf_Q7wKKBufCc1mtV1qVPVrOW0S1qhHxfOv6pJa2Kg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-10-04 13:02   ` Oleg Nesterov
     [not found]     ` <20131004130207.GA9338-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-10-07 18:45       ` Tejun Heo
     [not found]         ` <20131007184507.GD27396-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2013-10-08 14:58           ` Oleg Nesterov
     [not found]             ` <20131008145833.GA15600-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-10-09  5:35               ` Li Zefan
     [not found]                 ` <5254EB2A.7090803-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-10-09 13:30                   ` Oleg Nesterov
     [not found]                     ` <20131009133047.GA12414-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-10-09 14:05                       ` Oleg Nesterov
2013-10-09 16:54                         ` Oleg Nesterov [this message]
2013-10-09 16:54                           ` cgroup_attach_task && while_each_thread (Was: cgroup attach task - slogging cpu) Oleg Nesterov
2013-10-11 13:15                           ` Li Zefan
2013-10-11 13:15                             ` Li Zefan
2013-10-11 16:00                             ` Oleg Nesterov
2013-10-11 16:00                               ` Oleg Nesterov
2013-10-12  2:59                               ` [PATCH] cgroup: fix to break the while loop in cgroup_attach_task() correctly Li Zefan
2013-10-12  2:59                                 ` Li Zefan
2013-10-13 20:08                                 ` Tejun Heo
2013-10-13 20:08                                   ` Tejun Heo
2013-10-15  5:04                               ` cgroup_attach_task && while_each_thread (Was: cgroup attach task - slogging cpu) anjana vk
2013-10-15  5:04                                 ` anjana vk
2013-10-15 13:34                                 ` Tejun Heo
2013-10-15 13:34                                   ` Tejun Heo
     [not found]                         ` <CAChhN7RerxpSadqyosUeSKFg+qcOpO4d-maEKBZ0rvOQGvN27g@mail.gmail.com>
     [not found]                           ` <CAChhN7RerxpSadqyosUeSKFg+qcOpO4d-maEKBZ0rvOQGvN27g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-10-10  4:22                             ` cgroup attach task - slogging cpu anjana vk
2013-10-10 11:11                             ` Oleg Nesterov

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=20131009165448.GA22437@redhat.com \
    --to=oleg@redhat.com \
    --cc=anjanvk12@gmail.com \
    --cc=cgroups@vger.kernel.org \
    --cc=eunki_kim@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=tj@kernel.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 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.