All of lore.kernel.org
 help / color / mirror / Atom feed
From: Li Zefan <lizf@cn.fujitsu.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Tejun Heo <tj@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	Containers <containers@lists.linux-foundation.org>,
	Cgroups <cgroups@vger.kernel.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Oleg Nesterov <oleg@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Paul Menage <paul@paulmenage.org>,
	Mandeep Singh Baines <msb@chromium.org>
Subject: Re: [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork()
Date: Wed, 21 Dec 2011 10:16:22 +0800	[thread overview]
Message-ID: <4EF14176.9040206@cn.fujitsu.com> (raw)
In-Reply-To: <1324432958-20414-3-git-send-email-fweisbec@gmail.com>

Frederic Weisbecker wrote:
> We don't need to hold the parent task_lock() on the
> parent in cgroup_fork() because we are already synchronized
> against the two places that may change the parent css_set
> concurrently:
> 
> - cgroup_exit(), but the parent obviously can't exit concurrently
> - cgroup migration: we are synchronized against threadgroup_lock()
> 
> So we can safely remove the task_lock() there.
> 
> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Li Zefan <lizf@cn.fujitsu.com>
> Cc: Containers <containers@lists.linux-foundation.org>
> Cc: Cgroups <cgroups@vger.kernel.org>
> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> Cc: Oleg Nesterov <oleg@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Paul Menage <paul@paulmenage.org>
> Cc: Mandeep Singh Baines <msb@chromium.org>
> ---
>  kernel/cgroup.c |   10 +++++++---
>  1 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 24f6d6f..1999f60 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -4556,7 +4556,7 @@ static const struct file_operations proc_cgroupstats_operations = {
>   *
>   * A pointer to the shared css_set was automatically copied in
>   * fork.c by dup_task_struct().  However, we ignore that copy, since
> - * it was not made under the protection of RCU or cgroup_mutex, so
> + * it was not made under the protection of threadgroup_change_begin(), so

I think the original comment still stands, but now threadgroup_change_begin()
can also protect the cgroup pointer from becoming invalid.

>   * might no longer be a valid cgroup pointer.  cgroup_attach_task() might
>   * have already changed current->cgroups, allowing the previously
>   * referenced cgroup group to be removed and freed.
> @@ -4566,10 +4566,14 @@ static const struct file_operations proc_cgroupstats_operations = {
>   */
>  void cgroup_fork(struct task_struct *child)
>  {
> -	task_lock(current);
> +	/*
> +	 * We don't need to task_lock() current because current->cgroups
> +	 * can't be changed concurrently here. The parent obviously hasn't
> +	 * exited and called cgroup_exit(), and we are synchronized against
> +	 * cgroup migration through threadgroup_change_begin().
> +	 */
>  	child->cgroups = current->cgroups;
>  	get_css_set(child->cgroups);
> -	task_unlock(current);
>  	INIT_LIST_HEAD(&child->cg_list);
>  }
>  

WARNING: multiple messages have this Message-ID (diff)
From: Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
To: Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Containers
	<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	KAMEZAWA Hiroyuki
	<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>,
	Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	Paul Menage <paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org>,
	Mandeep Singh Baines
	<msb-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Subject: Re: [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork()
Date: Wed, 21 Dec 2011 10:16:22 +0800	[thread overview]
Message-ID: <4EF14176.9040206@cn.fujitsu.com> (raw)
In-Reply-To: <1324432958-20414-3-git-send-email-fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Frederic Weisbecker wrote:
> We don't need to hold the parent task_lock() on the
> parent in cgroup_fork() because we are already synchronized
> against the two places that may change the parent css_set
> concurrently:
> 
> - cgroup_exit(), but the parent obviously can't exit concurrently
> - cgroup migration: we are synchronized against threadgroup_lock()
> 
> So we can safely remove the task_lock() there.
> 
> Signed-off-by: Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
> Cc: Containers <containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
> Cc: Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
> Cc: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
> Cc: Paul Menage <paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org>
> Cc: Mandeep Singh Baines <msb-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
>  kernel/cgroup.c |   10 +++++++---
>  1 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 24f6d6f..1999f60 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -4556,7 +4556,7 @@ static const struct file_operations proc_cgroupstats_operations = {
>   *
>   * A pointer to the shared css_set was automatically copied in
>   * fork.c by dup_task_struct().  However, we ignore that copy, since
> - * it was not made under the protection of RCU or cgroup_mutex, so
> + * it was not made under the protection of threadgroup_change_begin(), so

I think the original comment still stands, but now threadgroup_change_begin()
can also protect the cgroup pointer from becoming invalid.

>   * might no longer be a valid cgroup pointer.  cgroup_attach_task() might
>   * have already changed current->cgroups, allowing the previously
>   * referenced cgroup group to be removed and freed.
> @@ -4566,10 +4566,14 @@ static const struct file_operations proc_cgroupstats_operations = {
>   */
>  void cgroup_fork(struct task_struct *child)
>  {
> -	task_lock(current);
> +	/*
> +	 * We don't need to task_lock() current because current->cgroups
> +	 * can't be changed concurrently here. The parent obviously hasn't
> +	 * exited and called cgroup_exit(), and we are synchronized against
> +	 * cgroup migration through threadgroup_change_begin().
> +	 */
>  	child->cgroups = current->cgroups;
>  	get_css_set(child->cgroups);
> -	task_unlock(current);
>  	INIT_LIST_HEAD(&child->cg_list);
>  }
>  

  parent reply	other threads:[~2011-12-21  2:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-21  2:02 [PATCH 0/2 v2] cgroup: Remove useless task_lock() Frederic Weisbecker
2011-12-21  2:02 ` Frederic Weisbecker
     [not found] ` <1324432958-20414-1-git-send-email-fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2011-12-21  2:02   ` [PATCH 1/2 v2] cgroup: Remove unnecessary task_lock before fetching css_set on migration Frederic Weisbecker
2011-12-21  2:02     ` Frederic Weisbecker
2011-12-21  2:02   ` [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork() Frederic Weisbecker
2011-12-21  2:02     ` Frederic Weisbecker
     [not found]     ` <1324432958-20414-3-git-send-email-fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2011-12-21  2:16       ` Li Zefan
2011-12-21  2:16     ` Li Zefan [this message]
2011-12-21  2:16       ` Li Zefan
     [not found]       ` <4EF14176.9040206-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2011-12-21  2:48         ` Frederic Weisbecker
2011-12-21  2:48       ` Frederic Weisbecker
2011-12-21  2:48         ` Frederic Weisbecker
2011-12-21  3:16         ` Li Zefan
2011-12-21  3:16           ` Li Zefan
     [not found]           ` <4EF14F7B.2040507-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2011-12-21 17:50             ` Tejun Heo
2011-12-21 17:50               ` Tejun Heo
2011-12-21 17:51               ` Tejun Heo
2011-12-21 17:51                 ` Tejun Heo
     [not found]               ` <20111221175024.GG9213-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2011-12-21 17:51                 ` Tejun Heo
2011-12-21 17:52                 ` Frederic Weisbecker
2011-12-21 17:52               ` Frederic Weisbecker
2011-12-21 17:52                 ` Frederic Weisbecker

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=4EF14176.9040206@cn.fujitsu.com \
    --to=lizf@cn.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=containers@lists.linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=msb@chromium.org \
    --cc=oleg@redhat.com \
    --cc=paul@paulmenage.org \
    --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.