summaryrefslogtreecommitdiffstats
path: root/kernel/up.c
diff options
context:
space:
mode:
authorAnjana V Kumar <anjanavk12@gmail.com>2013-10-12 10:59:17 +0800
committerTejun Heo <tj@kernel.org>2013-10-13 16:07:10 -0400
commitea84753c98a7ac6b74e530b64c444a912b3835ca (patch)
tree5e5f08d2c9a4f7fdc434d1fc7db3f7095809dd23 /kernel/up.c
parent58b79a91f57efec9457de8ff93a4cc4fb8daf753 (diff)
downloadop-kernel-dev-ea84753c98a7ac6b74e530b64c444a912b3835ca.zip
op-kernel-dev-ea84753c98a7ac6b74e530b64c444a912b3835ca.tar.gz
cgroup: fix to break the while loop in cgroup_attach_task() correctly
Both Anjana and Eunki reported a stall in the while_each_thread loop in cgroup_attach_task(). It's because, when we attach a single thread to a cgroup, if the cgroup is exiting or is already in that cgroup, we won't break the loop. If the task is already in the cgroup, the bug can lead to another thread being attached to the cgroup unexpectedly: # echo 5207 > tasks # cat tasks 5207 # echo 5207 > tasks # cat tasks 5207 5215 What's worse, if the task to be attached isn't the leader of the thread group, we might never exit the loop, hence cpu stall. Thanks for Oleg's analysis. This bug was introduced by commit 081aa458c38ba576bdd4265fc807fa95b48b9e79 ("cgroup: consolidate cgroup_attach_task() and cgroup_attach_proc()") [ lizf: - fixed the first continue, pointed out by Oleg, - rewrote changelog. ] Cc: <stable@vger.kernel.org> # 3.9+ Reported-by: Eunki Kim <eunki_kim@samsung.com> Reported-by: Anjana V Kumar <anjanavk12@gmail.com> Signed-off-by: Anjana V Kumar <anjanavk12@gmail.com> Signed-off-by: Li Zefan <lizefan@huawei.com> Signed-off-by: Tejun Heo <tj@kernel.org>
Diffstat (limited to 'kernel/up.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud