From: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Linux Kernel
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Alexander Viro
<viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH cgroup/for-3.10] cgroup: make cgroup_mutex outer to threadgroup_lock
Date: Wed, 20 Mar 2013 08:58:08 +0800 [thread overview]
Message-ID: <514909A0.4030808@huawei.com> (raw)
In-Reply-To: <20130319220246.GR3042-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
On 2013/3/20 6:02, Tejun Heo wrote:
> It doesn't make sense to nest cgroup_mutex inside threadgroup_lock
> when it should be outer to most all locks used by all cgroup
> controllers. It was nested inside threadgroup_lock only because some
> controllers were abusing cgroup_mutex inside controllers leading to
> locking order inversion.
>
> cgroup_mutex is no longer abused by controllers and can be put outer
> to threadgroup_lock. Reverse the locking order in
> attach_task_by_pid().
>
But the code contrast to the changelog. ;)
cgroup_mutex is currently outside of threadgroup_lock, and you're making
it nested inside threadgroup_lock in the code.
> Signed-off-by: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> ---
> Li, can you please ack this?
>
> Thanks!
>
> kernel/cgroup.c | 21 ++++++++-------------
> 1 file changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 04fa2ab..24106b8 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -2134,17 +2134,13 @@ static int attach_task_by_pid(struct cgroup *cgrp, u64 pid, bool threadgroup)
> const struct cred *cred = current_cred(), *tcred;
> int ret;
>
> - if (!cgroup_lock_live_group(cgrp))
> - return -ENODEV;
> -
> retry_find_task:
> rcu_read_lock();
> if (pid) {
> tsk = find_task_by_vpid(pid);
> if (!tsk) {
> rcu_read_unlock();
> - ret= -ESRCH;
> - goto out_unlock_cgroup;
> + return -ESRCH;
> }
> /*
> * even if we're attaching all tasks in the thread group, we
> @@ -2155,8 +2151,7 @@ retry_find_task:
> !uid_eq(cred->euid, tcred->uid) &&
> !uid_eq(cred->euid, tcred->suid)) {
> rcu_read_unlock();
> - ret = -EACCES;
> - goto out_unlock_cgroup;
> + return -EACCES;
> }
> } else
> tsk = current;
> @@ -2170,9 +2165,8 @@ retry_find_task:
> * with no rt_runtime allocated. Just say no.
> */
> if (tsk == kthreadd_task || (tsk->flags & PF_THREAD_BOUND)) {
> - ret = -EINVAL;
> rcu_read_unlock();
> - goto out_unlock_cgroup;
> + return -EINVAL;
> }
>
> get_task_struct(tsk);
> @@ -2194,13 +2188,14 @@ retry_find_task:
> }
> }
>
> - ret = cgroup_attach_task(cgrp, tsk, threadgroup);
> + ret = -ENODEV;
> + if (cgroup_lock_live_group(cgrp)) {
> + ret = cgroup_attach_task(cgrp, tsk, threadgroup);
> + cgroup_unlock();
> + }
>
> threadgroup_unlock(tsk);
> -
> put_task_struct(tsk);
> -out_unlock_cgroup:
> - cgroup_unlock();
> return ret;
> }
>
> .
>
WARNING: multiple messages have this Message-ID (diff)
From: Li Zefan <lizefan@huawei.com>
To: Tejun Heo <tj@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>, Dave Jones <davej@redhat.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
<cgroups@vger.kernel.org>
Subject: Re: [PATCH cgroup/for-3.10] cgroup: make cgroup_mutex outer to threadgroup_lock
Date: Wed, 20 Mar 2013 08:58:08 +0800 [thread overview]
Message-ID: <514909A0.4030808@huawei.com> (raw)
In-Reply-To: <20130319220246.GR3042@htj.dyndns.org>
On 2013/3/20 6:02, Tejun Heo wrote:
> It doesn't make sense to nest cgroup_mutex inside threadgroup_lock
> when it should be outer to most all locks used by all cgroup
> controllers. It was nested inside threadgroup_lock only because some
> controllers were abusing cgroup_mutex inside controllers leading to
> locking order inversion.
>
> cgroup_mutex is no longer abused by controllers and can be put outer
> to threadgroup_lock. Reverse the locking order in
> attach_task_by_pid().
>
But the code contrast to the changelog. ;)
cgroup_mutex is currently outside of threadgroup_lock, and you're making
it nested inside threadgroup_lock in the code.
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: Li Zefan <lizefan@huawei.com>
> ---
> Li, can you please ack this?
>
> Thanks!
>
> kernel/cgroup.c | 21 ++++++++-------------
> 1 file changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 04fa2ab..24106b8 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -2134,17 +2134,13 @@ static int attach_task_by_pid(struct cgroup *cgrp, u64 pid, bool threadgroup)
> const struct cred *cred = current_cred(), *tcred;
> int ret;
>
> - if (!cgroup_lock_live_group(cgrp))
> - return -ENODEV;
> -
> retry_find_task:
> rcu_read_lock();
> if (pid) {
> tsk = find_task_by_vpid(pid);
> if (!tsk) {
> rcu_read_unlock();
> - ret= -ESRCH;
> - goto out_unlock_cgroup;
> + return -ESRCH;
> }
> /*
> * even if we're attaching all tasks in the thread group, we
> @@ -2155,8 +2151,7 @@ retry_find_task:
> !uid_eq(cred->euid, tcred->uid) &&
> !uid_eq(cred->euid, tcred->suid)) {
> rcu_read_unlock();
> - ret = -EACCES;
> - goto out_unlock_cgroup;
> + return -EACCES;
> }
> } else
> tsk = current;
> @@ -2170,9 +2165,8 @@ retry_find_task:
> * with no rt_runtime allocated. Just say no.
> */
> if (tsk == kthreadd_task || (tsk->flags & PF_THREAD_BOUND)) {
> - ret = -EINVAL;
> rcu_read_unlock();
> - goto out_unlock_cgroup;
> + return -EINVAL;
> }
>
> get_task_struct(tsk);
> @@ -2194,13 +2188,14 @@ retry_find_task:
> }
> }
>
> - ret = cgroup_attach_task(cgrp, tsk, threadgroup);
> + ret = -ENODEV;
> + if (cgroup_lock_live_group(cgrp)) {
> + ret = cgroup_attach_task(cgrp, tsk, threadgroup);
> + cgroup_unlock();
> + }
>
> threadgroup_unlock(tsk);
> -
> put_task_struct(tsk);
> -out_unlock_cgroup:
> - cgroup_unlock();
> return ret;
> }
>
> .
>
next prev parent reply other threads:[~2013-03-20 0:58 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-06 22:36 lockdep trace from prepare_bprm_creds Dave Jones
[not found] ` <20130306223657.GA7392-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-03-07 17:25 ` Oleg Nesterov
2013-03-07 17:25 ` Oleg Nesterov
2013-03-07 18:01 ` Tejun Heo
[not found] ` <20130307180139.GD29601-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2013-03-07 18:03 ` Tejun Heo
2013-03-07 18:03 ` Tejun Heo
[not found] ` <20130307180332.GE29601-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2013-03-07 19:12 ` Oleg Nesterov
2013-03-07 19:12 ` Oleg Nesterov
[not found] ` <20130307191242.GA18265-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-03-07 19:38 ` Tejun Heo
2013-03-07 19:38 ` Tejun Heo
[not found] ` <20130307193820.GB3209-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2013-03-09 2:11 ` Li Zefan
2013-03-09 2:11 ` Li Zefan
[not found] ` <513A9A67.60909-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-03-09 3:29 ` Tejun Heo
2013-03-09 3:29 ` Tejun Heo
[not found] ` <20130309032936.GT14556-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2013-03-09 7:47 ` Li Zefan
2013-03-09 7:47 ` Li Zefan
[not found] ` <513AE918.7020704-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-03-09 20:00 ` [PATCH 0/1] do not abuse ->cred_guard_mutex in threadgroup_lock() Oleg Nesterov
2013-03-09 20:00 ` Oleg Nesterov
2013-03-09 20:01 ` [PATCH 1/1] " Oleg Nesterov
[not found] ` <20130309200106.GB8149-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-03-09 20:15 ` Tejun Heo
2013-03-09 20:15 ` Tejun Heo
2013-03-11 1:50 ` Li Zefan
2013-03-11 1:50 ` Li Zefan
[not found] ` <20130309200046.GA8149-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-03-21 16:21 ` [PATCH] " Oleg Nesterov
2013-03-21 16:21 ` Oleg Nesterov
[not found] ` <20130321162138.GA21859-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-03-21 22:06 ` Andrew Morton
2013-03-21 22:06 ` Andrew Morton
[not found] ` <20130321150626.a7934d989fb80d835fa92255-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2013-03-22 13:20 ` Oleg Nesterov
2013-03-22 13:20 ` Oleg Nesterov
2013-03-19 22:02 ` [PATCH cgroup/for-3.10] cgroup: make cgroup_mutex outer to threadgroup_lock Tejun Heo
[not found] ` <20130319220246.GR3042-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2013-03-20 0:58 ` Li Zefan [this message]
2013-03-20 0:58 ` Li Zefan
2013-03-20 15:03 ` Tejun Heo
[not found] ` <20130320150351.GW3042-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2013-03-20 18:35 ` Oleg Nesterov
2013-03-20 18:35 ` Oleg Nesterov
[not found] ` <20130320183523.GA29365-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-03-20 18:42 ` Tejun Heo
2013-03-20 18:42 ` Tejun Heo
[not found] ` <CAOS58YPxGXt+iq1GZ4hryqm1Z_p+r7eRRC7ruUDDd=LQrWtAxg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-21 16:17 ` Oleg Nesterov
2013-03-21 16:17 ` Oleg Nesterov
2013-03-07 18:21 ` lockdep trace from prepare_bprm_creds Tejun Heo
2013-03-07 18:21 ` Tejun Heo
[not found] ` <20130307182140.GF29601-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2013-03-07 18:32 ` Oleg Nesterov
2013-03-07 18:32 ` Oleg Nesterov
[not found] ` <20130307183213.GA18022-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-03-07 19:33 ` Tejun Heo
2013-03-07 19:33 ` Tejun Heo
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=514909A0.4030808@huawei.com \
--to=lizefan-hv44wf8li93qt0dzr+alfa@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.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.