All of lore.kernel.org
 help / color / mirror / Atom feed
From: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
Cc: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>,
	Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	KAMEZAWA Hiroyuki
	<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>,
	Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
Subject: Re: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()
Date: Tue, 26 Mar 2013 15:52:32 +0800	[thread overview]
Message-ID: <515153C0.5070908@huawei.com> (raw)
In-Reply-To: <20130325090629.GN2154-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>

>>> >From 7ed7f53bb597e8cb40d9ac91ce16142fb60f1e93 Mon Sep 17 00:00:00 2001
>>> From: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
>>> Date: Fri, 22 Mar 2013 10:22:54 +0100
>>> Subject: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()
>>>
>>> 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.
>>>
>>
>> I doubt it's a win to add 4K to kernel text size instead of adding
>> a few extra lines of code... but it's up to you.
> 
> I will leave the decision to Glauber. The updated version which uses
> kmalloc for the static buffer is bellow.
> 

I don't have strong preference. Glauber, what's your opinion?

...
>  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;

(minor nitpick) why not preserve the name "name"

WARNING: multiple messages have this Message-ID (diff)
From: Li Zefan <lizefan@huawei.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: Glauber Costa <glommer@parallels.com>, Tejun Heo <tj@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Cgroups <cgroups@vger.kernel.org>,
	linux-mm@kvack.org,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()
Date: Tue, 26 Mar 2013 15:52:32 +0800	[thread overview]
Message-ID: <515153C0.5070908@huawei.com> (raw)
In-Reply-To: <20130325090629.GN2154@dhcp22.suse.cz>

>>> >From 7ed7f53bb597e8cb40d9ac91ce16142fb60f1e93 Mon Sep 17 00:00:00 2001
>>> From: Michal Hocko <mhocko@suse.cz>
>>> Date: Fri, 22 Mar 2013 10:22:54 +0100
>>> Subject: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()
>>>
>>> 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.
>>>
>>
>> I doubt it's a win to add 4K to kernel text size instead of adding
>> a few extra lines of code... but it's up to you.
> 
> I will leave the decision to Glauber. The updated version which uses
> kmalloc for the static buffer is bellow.
> 

I don't have strong preference. Glauber, what's your opinion?

...
>  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;

(minor nitpick) why not preserve the name "name"

--
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: Li Zefan <lizefan@huawei.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: Glauber Costa <glommer@parallels.com>, Tejun Heo <tj@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Cgroups <cgroups@vger.kernel.org>, <linux-mm@kvack.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()
Date: Tue, 26 Mar 2013 15:52:32 +0800	[thread overview]
Message-ID: <515153C0.5070908@huawei.com> (raw)
In-Reply-To: <20130325090629.GN2154@dhcp22.suse.cz>

>>> >From 7ed7f53bb597e8cb40d9ac91ce16142fb60f1e93 Mon Sep 17 00:00:00 2001
>>> From: Michal Hocko <mhocko@suse.cz>
>>> Date: Fri, 22 Mar 2013 10:22:54 +0100
>>> Subject: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()
>>>
>>> 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.
>>>
>>
>> I doubt it's a win to add 4K to kernel text size instead of adding
>> a few extra lines of code... but it's up to you.
> 
> I will leave the decision to Glauber. The updated version which uses
> kmalloc for the static buffer is bellow.
> 

I don't have strong preference. Glauber, what's your opinion?

...
>  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;

(minor nitpick) why not preserve the name "name"


  parent reply	other threads:[~2013-03-26  7:52 UTC|newest]

Thread overview: 110+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-21  1:22 [PATCH] memcg: fix memcg_cache_name() to use cgroup_name() 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 [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2013-03-27  8:36 Michal Hocko
2013-03-27  8:36 ` Michal Hocko
2013-03-27  8:36 ` Michal Hocko
2013-03-27 14:58 ` Johannes Weiner
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

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=515153C0.5070908@huawei.com \
    --to=lizefan-hv44wf8li93qt0dzr+alfa@public.gmane.org \
    --cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org \
    --cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
    --cc=kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    --cc=mhocko-AlSwsSmVLrQ@public.gmane.org \
    --cc=tj-DgEjT+Ai2ygdnm+yROfE0A@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.