All of lore.kernel.org
 help / color / mirror / Atom feed
From: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To: Wanpeng Li <liwp.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
	Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>,
	Balbir Singh
	<bsingharora-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	AndrewMorton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	Eric Dumazet
	<eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>,
	Arun Sharma <asharma-b10kYP2dOMg@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 1/5 v2] memcg: replace unsigned long by u64 to avoid overflow
Date: Wed, 4 Jul 2012 16:29:48 +0400	[thread overview]
Message-ID: <4FF4373C.8020100@parallels.com> (raw)
In-Reply-To: <20120704122427.GA21598@kernel>

On 07/04/2012 04:24 PM, Wanpeng Li wrote:
> On Mon, Jun 25, 2012 at 05:30:11PM +0900, Kamezawa Hiroyuki wrote:
>> (2012/06/25 16:52), Johannes Weiner wrote:
>>> On Mon, Jun 25, 2012 at 02:04:20PM +0800, Wanpeng Li wrote:
>>>> Changlog:
>>>>
>>>> V2 -> V1:
>>>> * fix zone_page_state()::/include/linux/vmstat.h returns 'unsigned long'
>>>>
>>>> From: Wanpeng Li <liwp-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>>>>
>>>> Since the return value variable in mem_cgroup_zone_nr_lru_pages and
>>>> mem_cgroup_node_nr_lru_pages functions are u64, so replace the return
>>>> value of funtions by u64 to avoid overflow.
>>>>
>>>> Signed-off-by: Wanpeng Li <liwp.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> ---
>>>>  include/linux/vmstat.h |    2 +-
>>>>  mm/memcontrol.c        |    5 ++---
>>>>  2 files changed, 3 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
>>>> index 65efb92..6a14291 100644
>>>> --- a/include/linux/vmstat.h
>>>> +++ b/include/linux/vmstat.h
>>>> @@ -106,7 +106,7 @@ static inline unsigned long global_page_state(enum zone_stat_item item)
>>>>  	return x;
>>>>  }
>>>>
>>>> -static inline unsigned long zone_page_state(struct zone *zone,
>>>> +static inline u64 zone_page_state(struct zone *zone,
>>>>  					enum zone_stat_item item)
>>>>  {
>>>>  	long x = atomic_long_read(&zone->vm_stat[item]);
>>>
>>> We established that there is no known reason to use ulong for page
>>> counters and that IF YOU HAD ONE, you should obviously say so and then
>>> do a wholesale conversion.  But I don't think you have one.
>>>
>>> This patch makes absolutely no sense.
>>>
>> I agree. Then, Nack from me.
>>
>> Thanks,
>> -Kame
> 
> static unsigned long
> mem_cgroup_node_nr_lru_pages(struct mem_cgroup *memcg,
> 			int nid, unsigned int lru_mask)
> {
> 	u64 total = 0;
> 	int zid;
> 
> 	for (zid = 0; zid < MAX_NR_ZONES; zid++)
> 		total += mem_cgroup_zone_nr_lru_pages(memcg,
> 					    nid, zid, lru_mask);
> 
> 	return total;
> }
> 
> Since you use unsigned long to caculate nr_pages and unsigned long long
> to caculate bytes, so u64 in function mem_cgroup_node_nr_lru_pages should 
> replace by unsigned long to save kernel stack, right?

How many bytes do you intend to save by replacing "u64" with "unsigned
long" ? Have you asked yourself this question ?






WARNING: multiple messages have this Message-ID (diff)
From: Glauber Costa <glommer@parallels.com>
To: Wanpeng Li <liwp.linux@gmail.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
	Michal Hocko <mhocko@suse.cz>,
	Balbir Singh <bsingharora@gmail.com>,
	AndrewMorton <akpm@linux-foundation.org>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Mike Frysinger <vapier@gentoo.org>, Arun Sharma <asharma@fb.com>,
	<linux-kernel@vger.kernel.org>, <cgroups@vger.kernel.org>
Subject: Re: [PATCH 1/5 v2] memcg: replace unsigned long by u64 to avoid overflow
Date: Wed, 4 Jul 2012 16:29:48 +0400	[thread overview]
Message-ID: <4FF4373C.8020100@parallels.com> (raw)
In-Reply-To: <20120704122427.GA21598@kernel>

On 07/04/2012 04:24 PM, Wanpeng Li wrote:
> On Mon, Jun 25, 2012 at 05:30:11PM +0900, Kamezawa Hiroyuki wrote:
>> (2012/06/25 16:52), Johannes Weiner wrote:
>>> On Mon, Jun 25, 2012 at 02:04:20PM +0800, Wanpeng Li wrote:
>>>> Changlog:
>>>>
>>>> V2 -> V1:
>>>> * fix zone_page_state()::/include/linux/vmstat.h returns 'unsigned long'
>>>>
>>>> From: Wanpeng Li <liwp@linux.vnet.ibm.com>
>>>>
>>>> Since the return value variable in mem_cgroup_zone_nr_lru_pages and
>>>> mem_cgroup_node_nr_lru_pages functions are u64, so replace the return
>>>> value of funtions by u64 to avoid overflow.
>>>>
>>>> Signed-off-by: Wanpeng Li <liwp.linux@gmail.com>
>>>> ---
>>>>  include/linux/vmstat.h |    2 +-
>>>>  mm/memcontrol.c        |    5 ++---
>>>>  2 files changed, 3 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
>>>> index 65efb92..6a14291 100644
>>>> --- a/include/linux/vmstat.h
>>>> +++ b/include/linux/vmstat.h
>>>> @@ -106,7 +106,7 @@ static inline unsigned long global_page_state(enum zone_stat_item item)
>>>>  	return x;
>>>>  }
>>>>
>>>> -static inline unsigned long zone_page_state(struct zone *zone,
>>>> +static inline u64 zone_page_state(struct zone *zone,
>>>>  					enum zone_stat_item item)
>>>>  {
>>>>  	long x = atomic_long_read(&zone->vm_stat[item]);
>>>
>>> We established that there is no known reason to use ulong for page
>>> counters and that IF YOU HAD ONE, you should obviously say so and then
>>> do a wholesale conversion.  But I don't think you have one.
>>>
>>> This patch makes absolutely no sense.
>>>
>> I agree. Then, Nack from me.
>>
>> Thanks,
>> -Kame
> 
> static unsigned long
> mem_cgroup_node_nr_lru_pages(struct mem_cgroup *memcg,
> 			int nid, unsigned int lru_mask)
> {
> 	u64 total = 0;
> 	int zid;
> 
> 	for (zid = 0; zid < MAX_NR_ZONES; zid++)
> 		total += mem_cgroup_zone_nr_lru_pages(memcg,
> 					    nid, zid, lru_mask);
> 
> 	return total;
> }
> 
> Since you use unsigned long to caculate nr_pages and unsigned long long
> to caculate bytes, so u64 in function mem_cgroup_node_nr_lru_pages should 
> replace by unsigned long to save kernel stack, right?

How many bytes do you intend to save by replacing "u64" with "unsigned
long" ? Have you asked yourself this question ?







  reply	other threads:[~2012-07-04 12:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-25  6:04 [PATCH 1/5 v2] memcg: replace unsigned long by u64 to avoid overflow Wanpeng Li
2012-06-25  6:04 ` Wanpeng Li
     [not found] ` <1340604266-7937-1-git-send-email-liwp.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-06-25  7:52   ` Johannes Weiner
2012-06-25  7:52     ` Johannes Weiner
     [not found]     ` <20120625075215.GW27816-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2012-06-25  8:30       ` Kamezawa Hiroyuki
2012-06-25  8:30         ` Kamezawa Hiroyuki
     [not found]         ` <4FE82193.1070307-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-07-04 12:24           ` Wanpeng Li
2012-07-04 12:24             ` Wanpeng Li
2012-07-04 12:29             ` Glauber Costa [this message]
2012-07-04 12:29               ` Glauber Costa
     [not found]               ` <4FF4373C.8020100-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-07-04 13:16                 ` Johannes Weiner
2012-07-04 13:16                   ` Johannes Weiner
     [not found]                   ` <20120704131631.GD7881-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2012-07-04 13:18                     ` Glauber Costa
2012-07-04 13:18                       ` 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=4FF4373C.8020100@parallels.com \
    --to=glommer-bzqdu9zft3wakbo8gow8eq@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=asharma-b10kYP2dOMg@public.gmane.org \
    --cc=bsingharora-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=liwp.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=mhocko-AlSwsSmVLrQ@public.gmane.org \
    --cc=vapier-aBrp7R+bbdUdnm+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.