All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Michal Hocko <mhocko@suse.cz>
Cc: Tejun Heo <tj@kernel.org>, Glauber Costa <glommer@parallels.com>,
	Li Zefan <lizefan@huawei.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	linux-mm@kvack.org, cgroups@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()
Date: Wed, 27 Mar 2013 10:58:25 -0400	[thread overview]
Message-ID: <20130327145727.GD29052@cmpxchg.org> (raw)
In-Reply-To: <1364373399-17397-1-git-send-email-mhocko@suse.cz>

On Wed, Mar 27, 2013 at 09:36:39AM +0100, Michal Hocko wrote:
> As cgroup supports rename, it's unsafe to dereference dentry->d_name
> without proper vfs locks. Fix this by using cgroup_name() rather than
> dentry directly.
> 
> Also open code memcg_cache_name because it is called only from
> kmem_cache_dup which frees the returned name right after
> kmem_cache_create_memcg makes a copy of it. Such a short-lived
> allocation doesn't make too much sense. So replace it by a static
> buffer as kmem_cache_dup is called with memcg_cache_mutex.
> 
> Signed-off-by: Li Zefan <lizefan@huawei.com>
> Signed-off-by: Michal Hocko <mhocko@suse.cz>
> Acked-by: Glauber Costa <glommer@parallels.com>
> ---
>  mm/memcontrol.c |   64 ++++++++++++++++++++++++++++---------------------------
>  1 file changed, 33 insertions(+), 31 deletions(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index f608546..b30547b 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3364,52 +3364,54 @@ void mem_cgroup_destroy_cache(struct kmem_cache *cachep)
>  	schedule_work(&cachep->memcg_params->destroy);
>  }
>  
> -static char *memcg_cache_name(struct mem_cgroup *memcg, struct kmem_cache *s)
> -{
> -	char *name;
> -	struct dentry *dentry;
> -
> -	rcu_read_lock();
> -	dentry = rcu_dereference(memcg->css.cgroup->dentry);
> -	rcu_read_unlock();
> -
> -	BUG_ON(dentry == NULL);
> -
> -	name = kasprintf(GFP_KERNEL, "%s(%d:%s)", s->name,
> -			 memcg_cache_id(memcg), dentry->d_name.name);
> -
> -	return name;
> -}
> +/*
> + * This lock protects updaters, not readers. We want readers to be as fast as
> + * they can, and they will either see NULL or a valid cache value. Our model
> + * allow them to see NULL, in which case the root memcg will be selected.
> + *
> + * We need this lock because multiple allocations to the same cache from a non
> + * will span more than one worker. Only one of them can create the cache.
> + */
> +static DEFINE_MUTEX(memcg_cache_mutex);
>  
> +/*
> + * Called with memcg_cache_mutex held
> + */
>  static struct kmem_cache *kmem_cache_dup(struct mem_cgroup *memcg,
>  					 struct kmem_cache *s)
>  {
> -	char *name;
>  	struct kmem_cache *new;
> +	static char *tmp_name = NULL;
>  
> -	name = memcg_cache_name(memcg, s);
> -	if (!name)
> -		return NULL;
> +	lockdep_assert_held(&memcg_cache_mutex);
> +
> +	/*
> +	 * kmem_cache_create_memcg duplicates the given name and
> +	 * cgroup_name for this name requires RCU context.
> +	 * This static temporary buffer is used to prevent from
> +	 * pointless shortliving allocation.
> +	 */
> +	if (!tmp_name) {
> +		tmp_name = kmalloc(PAGE_SIZE, GFP_KERNEL);
> +		WARN_ON_ONCE(!tmp_name);

Just use the page allocator directly and get a free allocation failure
warning.  Then again, order-0 pages are considered cheap enough that
they never even fail in our current implementation.

Which brings me to my other point: why not just a simple single-page
allocation?  This just seems a little overelaborate.  I think this
path would be taken predominantly after cgroup creation and fork where
we do a bunch of allocations anyway.  And it happens asynchroneously
from userspace, so it's not even really performance critical.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: Michal Hocko <mhocko@suse.cz>
Cc: Tejun Heo <tj@kernel.org>, Glauber Costa <glommer@parallels.com>,
	Li Zefan <lizefan@huawei.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	linux-mm@kvack.org, cgroups@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()
Date: Wed, 27 Mar 2013 10:58:25 -0400	[thread overview]
Message-ID: <20130327145727.GD29052@cmpxchg.org> (raw)
In-Reply-To: <1364373399-17397-1-git-send-email-mhocko@suse.cz>

On Wed, Mar 27, 2013 at 09:36:39AM +0100, Michal Hocko wrote:
> As cgroup supports rename, it's unsafe to dereference dentry->d_name
> without proper vfs locks. Fix this by using cgroup_name() rather than
> dentry directly.
> 
> Also open code memcg_cache_name because it is called only from
> kmem_cache_dup which frees the returned name right after
> kmem_cache_create_memcg makes a copy of it. Such a short-lived
> allocation doesn't make too much sense. So replace it by a static
> buffer as kmem_cache_dup is called with memcg_cache_mutex.
> 
> Signed-off-by: Li Zefan <lizefan@huawei.com>
> Signed-off-by: Michal Hocko <mhocko@suse.cz>
> Acked-by: Glauber Costa <glommer@parallels.com>
> ---
>  mm/memcontrol.c |   64 ++++++++++++++++++++++++++++---------------------------
>  1 file changed, 33 insertions(+), 31 deletions(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index f608546..b30547b 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3364,52 +3364,54 @@ void mem_cgroup_destroy_cache(struct kmem_cache *cachep)
>  	schedule_work(&cachep->memcg_params->destroy);
>  }
>  
> -static char *memcg_cache_name(struct mem_cgroup *memcg, struct kmem_cache *s)
> -{
> -	char *name;
> -	struct dentry *dentry;
> -
> -	rcu_read_lock();
> -	dentry = rcu_dereference(memcg->css.cgroup->dentry);
> -	rcu_read_unlock();
> -
> -	BUG_ON(dentry == NULL);
> -
> -	name = kasprintf(GFP_KERNEL, "%s(%d:%s)", s->name,
> -			 memcg_cache_id(memcg), dentry->d_name.name);
> -
> -	return name;
> -}
> +/*
> + * This lock protects updaters, not readers. We want readers to be as fast as
> + * they can, and they will either see NULL or a valid cache value. Our model
> + * allow them to see NULL, in which case the root memcg will be selected.
> + *
> + * We need this lock because multiple allocations to the same cache from a non
> + * will span more than one worker. Only one of them can create the cache.
> + */
> +static DEFINE_MUTEX(memcg_cache_mutex);
>  
> +/*
> + * Called with memcg_cache_mutex held
> + */
>  static struct kmem_cache *kmem_cache_dup(struct mem_cgroup *memcg,
>  					 struct kmem_cache *s)
>  {
> -	char *name;
>  	struct kmem_cache *new;
> +	static char *tmp_name = NULL;
>  
> -	name = memcg_cache_name(memcg, s);
> -	if (!name)
> -		return NULL;
> +	lockdep_assert_held(&memcg_cache_mutex);
> +
> +	/*
> +	 * kmem_cache_create_memcg duplicates the given name and
> +	 * cgroup_name for this name requires RCU context.
> +	 * This static temporary buffer is used to prevent from
> +	 * pointless shortliving allocation.
> +	 */
> +	if (!tmp_name) {
> +		tmp_name = kmalloc(PAGE_SIZE, GFP_KERNEL);
> +		WARN_ON_ONCE(!tmp_name);

Just use the page allocator directly and get a free allocation failure
warning.  Then again, order-0 pages are considered cheap enough that
they never even fail in our current implementation.

Which brings me to my other point: why not just a simple single-page
allocation?  This just seems a little overelaborate.  I think this
path would be taken predominantly after cgroup creation and fork where
we do a bunch of allocations anyway.  And it happens asynchroneously
from userspace, so it's not even really performance critical.

  reply	other threads:[~2013-03-27 14:58 UTC|newest]

Thread overview: 110+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-27  8:36 [PATCH] memcg: fix memcg_cache_name() to use cgroup_name() Michal Hocko
2013-03-27  8:36 ` Michal Hocko
2013-03-27  8:36 ` Michal Hocko
2013-03-27 14:58 ` Johannes Weiner [this message]
2013-03-27 14:58   ` Johannes Weiner
     [not found]   ` <20130327145727.GD29052-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-03-27 15:11     ` Michal Hocko
2013-03-27 15:11       ` Michal Hocko
2013-03-27 15:11       ` Michal Hocko
     [not found]       ` <20130327151104.GK16579-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-03-27 15:19         ` Glauber Costa
2013-03-27 15:19           ` Glauber Costa
2013-03-27 15:19           ` Glauber Costa
2013-03-27 15:32           ` Michal Hocko
2013-03-27 15:32             ` Michal Hocko
     [not found]             ` <20130327153220.GL16579-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-03-27 17:32               ` Michal Hocko
2013-03-27 17:32                 ` Michal Hocko
2013-03-27 17:32                 ` Michal Hocko
     [not found]                 ` <20130327173223.GQ16579-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-03-28  7:48                   ` Michal Hocko
2013-03-28  7:48                     ` Michal Hocko
2013-03-28  7:48                     ` Michal Hocko
2013-04-02  8:26                     ` Michal Hocko
2013-04-02  8:26                       ` Michal Hocko
     [not found]                       ` <20130402082648.GB24345-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-04-03 21:33                         ` Tejun Heo
2013-04-03 21:33                           ` Tejun Heo
2013-04-03 21:33                           ` Tejun Heo
2013-04-04  7:06                           ` Michal Hocko
2013-04-04  7:06                             ` Michal Hocko
2013-03-27 15:32       ` Johannes Weiner
2013-03-27 15:32         ` Johannes Weiner
2013-03-27 15:47         ` Michal Hocko
2013-03-27 15:47           ` Michal Hocko
     [not found] ` <1364373399-17397-1-git-send-email-mhocko-AlSwsSmVLrQ@public.gmane.org>
2013-03-27 16:15   ` Tejun Heo
2013-03-27 16:15     ` Tejun Heo
2013-03-27 16:15     ` Tejun Heo
2013-03-27 16:19     ` Michal Hocko
2013-03-27 16:19       ` Michal Hocko
     [not found]       ` <20130327161905.GN16579-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-03-27 16:21         ` Tejun Heo
2013-03-27 16:21           ` Tejun Heo
2013-03-27 16:21           ` Tejun Heo
     [not found]           ` <CAOS58YPsrZNU9qDeMgJG3-Hkn0cBaigz16eTS5M57G95E8fxUQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-27 16:27             ` Michal Hocko
2013-03-27 16:27               ` Michal Hocko
2013-03-27 16:27               ` Michal Hocko
2013-03-28  7:22               ` Glauber Costa
2013-03-28  7:22                 ` Glauber Costa
2013-03-28  7:22                 ` Glauber Costa
  -- strict thread matches above, loose matches on Subject: below --
2013-03-21  1:22 Li Zefan
2013-03-21  1:22 ` Li Zefan
2013-03-21  9:08 ` Michal Hocko
2013-03-21  9:08   ` Michal Hocko
     [not found]   ` <20130321090849.GF6094-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-03-21 10:22     ` Michal Hocko
2013-03-21 10:22       ` Michal Hocko
2013-03-21 10:22       ` Michal Hocko
2013-03-22  1:22       ` Li Zefan
2013-03-22  1:22         ` Li Zefan
     [not found]         ` <514BB23E.70908-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-03-22  8:07           ` Michal Hocko
2013-03-22  8:07             ` Michal Hocko
2013-03-22  8:07             ` Michal Hocko
     [not found]             ` <20130322080749.GB31457-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-03-22  8:17               ` Li Zefan
2013-03-22  8:17                 ` Li Zefan
2013-03-22  8:17                 ` Li Zefan
     [not found]                 ` <514C1388.6090909-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-03-22  8:22                   ` Glauber Costa
2013-03-22  8:22                     ` Glauber Costa
2013-03-22  8:22                     ` Glauber Costa
2013-03-22  9:31                     ` Michal Hocko
2013-03-22  9:31                       ` Michal Hocko
2013-03-22  9:31                       ` Michal Hocko
2013-03-22  9:41                       ` Glauber Costa
2013-03-22  9:41                         ` Glauber Costa
     [not found]                         ` <514C2754.4080701-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-03-22  9:48                           ` Michal Hocko
2013-03-22  9:48                             ` Michal Hocko
2013-03-22  9:48                             ` Michal Hocko
     [not found]                             ` <20130322094832.GG31457-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-03-22 10:03                               ` Glauber Costa
2013-03-22 10:03                                 ` Glauber Costa
2013-03-22 10:03                                 ` Glauber Costa
2013-03-22 10:06                                 ` Michal Hocko
2013-03-22 10:06                                   ` Michal Hocko
     [not found]                                   ` <20130322100609.GI31457-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-03-22 10:25                                     ` Glauber Costa
2013-03-22 10:25                                       ` Glauber Costa
2013-03-22 10:25                                       ` Glauber Costa
     [not found]                                       ` <514C3193.9010609-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-03-22 10:56                                         ` Michal Hocko
2013-03-22 10:56                                           ` Michal Hocko
2013-03-22 10:56                                           ` Michal Hocko
2013-03-24  7:34                                           ` Li Zefan
2013-03-24  7:34                                             ` Li Zefan
2013-03-25  8:20                                             ` Michal Hocko
2013-03-25  8:20                                               ` Michal Hocko
2013-03-24  7:33                       ` Li Zefan
2013-03-24  7:33                         ` Li Zefan
     [not found]                         ` <514EAC41.5050700-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-03-25  9:06                           ` Michal Hocko
2013-03-25  9:06                             ` Michal Hocko
2013-03-25  9:06                             ` Michal Hocko
     [not found]                             ` <20130325090629.GN2154-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-03-26  7:52                               ` Li Zefan
2013-03-26  7:52                                 ` Li Zefan
2013-03-26  7:52                                 ` Li Zefan
     [not found]                                 ` <515153C0.5070908-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-03-26  8:10                                   ` Michal Hocko
2013-03-26  8:10                                     ` Michal Hocko
2013-03-26  8:10                                     ` Michal Hocko
2013-03-26  8:35                             ` Glauber Costa
2013-03-26  8:35                               ` Glauber Costa
2013-03-26  8:35                               ` Glauber Costa
     [not found]                               ` <51515DEE.70105-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-03-26  8:43                                 ` Michal Hocko
2013-03-26  8:43                                   ` Michal Hocko
2013-03-26  8:43                                   ` Michal Hocko
     [not found]                                   ` <20130326084348.GJ2295-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-03-26  9:02                                     ` Glauber Costa
2013-03-26  9:02                                       ` Glauber Costa
2013-03-26  9:02                                       ` Glauber Costa
     [not found]                                       ` <51516410.2000007-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-03-27  1:15                                         ` Li Zefan
2013-03-27  1:15                                           ` Li Zefan
2013-03-27  1:15                                           ` Li Zefan
2013-03-27  8:37                                           ` Michal Hocko
2013-03-27  8:37                                             ` Michal Hocko

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=20130327145727.GD29052@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=cgroups@vger.kernel.org \
    --cc=glommer@parallels.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lizefan@huawei.com \
    --cc=mhocko@suse.cz \
    --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.