* mm: Do not iterate over NR_CPUS in __zone_pcp_update()
@ 2010-03-08 9:21 ` Thomas Gleixner
0 siblings, 0 replies; 28+ messages in thread
From: Thomas Gleixner @ 2010-03-08 9:21 UTC (permalink / raw)
To: LKML; +Cc: linux-mm, Pekka Enberg, Christoph Lameter
__zone_pcp_update() iterates over NR_CPUS instead of limiting the
access to the possible cpus. This might result in access to
uninitialized areas as the per cpu allocator only populates the per
cpu memory for possible cpus.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
mm/page_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/mm/page_alloc.c
===================================================================
--- linux-2.6.orig/mm/page_alloc.c
+++ linux-2.6/mm/page_alloc.c
@@ -3224,7 +3224,7 @@ static int __zone_pcp_update(void *data)
int cpu;
unsigned long batch = zone_batchsize(zone), flags;
- for (cpu = 0; cpu < NR_CPUS; cpu++) {
+ for_each_possible_cpu(cpu) {
struct per_cpu_pageset *pset;
struct per_cpu_pages *pcp;
--
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>
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
2010-03-08 9:21 ` Thomas Gleixner
@ 2010-03-08 13:29 ` Pekka Enberg
-1 siblings, 0 replies; 28+ messages in thread
From: Pekka Enberg @ 2010-03-08 13:29 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, linux-mm, Christoph Lameter, Andrew Morton, Mel Gorman,
Tejun Heo
On Mon, Mar 8, 2010 at 11:21 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> __zone_pcp_update() iterates over NR_CPUS instead of limiting the
> access to the possible cpus. This might result in access to
> uninitialized areas as the per cpu allocator only populates the per
> cpu memory for possible cpus.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Looks OK to me.
Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>
> ---
> mm/page_alloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6/mm/page_alloc.c
> ===================================================================
> --- linux-2.6.orig/mm/page_alloc.c
> +++ linux-2.6/mm/page_alloc.c
> @@ -3224,7 +3224,7 @@ static int __zone_pcp_update(void *data)
> int cpu;
> unsigned long batch = zone_batchsize(zone), flags;
>
> - for (cpu = 0; cpu < NR_CPUS; cpu++) {
> + for_each_possible_cpu(cpu) {
> struct per_cpu_pageset *pset;
> struct per_cpu_pages *pcp;
>
>
> --
> 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>
>
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
@ 2010-03-08 13:29 ` Pekka Enberg
0 siblings, 0 replies; 28+ messages in thread
From: Pekka Enberg @ 2010-03-08 13:29 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, linux-mm, Christoph Lameter, Andrew Morton, Mel Gorman,
Tejun Heo
On Mon, Mar 8, 2010 at 11:21 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> __zone_pcp_update() iterates over NR_CPUS instead of limiting the
> access to the possible cpus. This might result in access to
> uninitialized areas as the per cpu allocator only populates the per
> cpu memory for possible cpus.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Looks OK to me.
Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>
> ---
> mm/page_alloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6/mm/page_alloc.c
> ===================================================================
> --- linux-2.6.orig/mm/page_alloc.c
> +++ linux-2.6/mm/page_alloc.c
> @@ -3224,7 +3224,7 @@ static int __zone_pcp_update(void *data)
> int cpu;
> unsigned long batch = zone_batchsize(zone), flags;
>
> - for (cpu = 0; cpu < NR_CPUS; cpu++) {
> + for_each_possible_cpu(cpu) {
> struct per_cpu_pageset *pset;
> struct per_cpu_pages *pcp;
>
>
> --
> 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>
>
--
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>
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
2010-03-08 13:29 ` Pekka Enberg
@ 2010-03-09 2:06 ` Tejun Heo
-1 siblings, 0 replies; 28+ messages in thread
From: Tejun Heo @ 2010-03-09 2:06 UTC (permalink / raw)
To: Pekka Enberg
Cc: Thomas Gleixner, LKML, linux-mm, Christoph Lameter, Andrew Morton,
Mel Gorman
On 03/08/2010 10:29 PM, Pekka Enberg wrote:
> On Mon, Mar 8, 2010 at 11:21 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> __zone_pcp_update() iterates over NR_CPUS instead of limiting the
>> access to the possible cpus. This might result in access to
>> uninitialized areas as the per cpu allocator only populates the per
>> cpu memory for possible cpus.
>>
>> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>
> Looks OK to me.
>
> Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>
Yeap, that's buggy.
Acked-by: Tejun Heo <tj@kernel.org>
I suppose this would go through the mm tree?
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
@ 2010-03-09 2:06 ` Tejun Heo
0 siblings, 0 replies; 28+ messages in thread
From: Tejun Heo @ 2010-03-09 2:06 UTC (permalink / raw)
To: Pekka Enberg
Cc: Thomas Gleixner, LKML, linux-mm, Christoph Lameter, Andrew Morton,
Mel Gorman
On 03/08/2010 10:29 PM, Pekka Enberg wrote:
> On Mon, Mar 8, 2010 at 11:21 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> __zone_pcp_update() iterates over NR_CPUS instead of limiting the
>> access to the possible cpus. This might result in access to
>> uninitialized areas as the per cpu allocator only populates the per
>> cpu memory for possible cpus.
>>
>> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>
> Looks OK to me.
>
> Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>
Yeap, that's buggy.
Acked-by: Tejun Heo <tj@kernel.org>
I suppose this would go through the mm tree?
Thanks.
--
tejun
--
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>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
2010-03-09 2:06 ` Tejun Heo
@ 2010-03-09 15:10 ` Christoph Lameter
-1 siblings, 0 replies; 28+ messages in thread
From: Christoph Lameter @ 2010-03-09 15:10 UTC (permalink / raw)
To: Tejun Heo
Cc: Pekka Enberg, Thomas Gleixner, LKML, linux-mm, Andrew Morton,
Mel Gorman
On Tue, 9 Mar 2010, Tejun Heo wrote:
> Yeap, that's buggy.
>
> Acked-by: Tejun Heo <tj@kernel.org>
>
> I suppose this would go through the mm tree?
As you said: Its a bug so it needs to be applied to upstream.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
@ 2010-03-09 15:10 ` Christoph Lameter
0 siblings, 0 replies; 28+ messages in thread
From: Christoph Lameter @ 2010-03-09 15:10 UTC (permalink / raw)
To: Tejun Heo
Cc: Pekka Enberg, Thomas Gleixner, LKML, linux-mm, Andrew Morton,
Mel Gorman
On Tue, 9 Mar 2010, Tejun Heo wrote:
> Yeap, that's buggy.
>
> Acked-by: Tejun Heo <tj@kernel.org>
>
> I suppose this would go through the mm tree?
As you said: Its a bug so it needs to be applied to upstream.
--
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>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
2010-03-09 15:10 ` Christoph Lameter
@ 2010-03-09 20:04 ` Pekka Enberg
-1 siblings, 0 replies; 28+ messages in thread
From: Pekka Enberg @ 2010-03-09 20:04 UTC (permalink / raw)
To: Christoph Lameter
Cc: Tejun Heo, Thomas Gleixner, LKML, linux-mm, Andrew Morton,
Mel Gorman
Christoph Lameter wrote:
> On Tue, 9 Mar 2010, Tejun Heo wrote:
>
>> Yeap, that's buggy.
>>
>> Acked-by: Tejun Heo <tj@kernel.org>
>>
>> I suppose this would go through the mm tree?
>
> As you said: Its a bug so it needs to be applied to upstream.
Sure but someone needs to pick up the patch and send it to Linus. Andrew?
Pekka
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
@ 2010-03-09 20:04 ` Pekka Enberg
0 siblings, 0 replies; 28+ messages in thread
From: Pekka Enberg @ 2010-03-09 20:04 UTC (permalink / raw)
To: Christoph Lameter
Cc: Tejun Heo, Thomas Gleixner, LKML, linux-mm, Andrew Morton,
Mel Gorman
Christoph Lameter wrote:
> On Tue, 9 Mar 2010, Tejun Heo wrote:
>
>> Yeap, that's buggy.
>>
>> Acked-by: Tejun Heo <tj@kernel.org>
>>
>> I suppose this would go through the mm tree?
>
> As you said: Its a bug so it needs to be applied to upstream.
Sure but someone needs to pick up the patch and send it to Linus. Andrew?
Pekka
--
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>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
2010-03-09 20:04 ` Pekka Enberg
@ 2010-03-09 20:19 ` Andrew Morton
-1 siblings, 0 replies; 28+ messages in thread
From: Andrew Morton @ 2010-03-09 20:19 UTC (permalink / raw)
To: Pekka Enberg
Cc: Christoph Lameter, Tejun Heo, Thomas Gleixner, LKML, linux-mm,
Mel Gorman
On Tue, 09 Mar 2010 22:04:02 +0200
Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> Christoph Lameter wrote:
> > On Tue, 9 Mar 2010, Tejun Heo wrote:
> >
> >> Yeap, that's buggy.
> >>
> >> Acked-by: Tejun Heo <tj@kernel.org>
> >>
> >> I suppose this would go through the mm tree?
> >
> > As you said: Its a bug so it needs to be applied to upstream.
>
> Sure but someone needs to pick up the patch and send it to Linus. Andrew?
>
yup, I found the patch.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
@ 2010-03-09 20:19 ` Andrew Morton
0 siblings, 0 replies; 28+ messages in thread
From: Andrew Morton @ 2010-03-09 20:19 UTC (permalink / raw)
To: Pekka Enberg
Cc: Christoph Lameter, Tejun Heo, Thomas Gleixner, LKML, linux-mm,
Mel Gorman
On Tue, 09 Mar 2010 22:04:02 +0200
Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> Christoph Lameter wrote:
> > On Tue, 9 Mar 2010, Tejun Heo wrote:
> >
> >> Yeap, that's buggy.
> >>
> >> Acked-by: Tejun Heo <tj@kernel.org>
> >>
> >> I suppose this would go through the mm tree?
> >
> > As you said: Its a bug so it needs to be applied to upstream.
>
> Sure but someone needs to pick up the patch and send it to Linus. Andrew?
>
yup, I found the patch.
--
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>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
2010-03-08 9:21 ` Thomas Gleixner
@ 2010-03-08 15:59 ` Christoph Lameter
-1 siblings, 0 replies; 28+ messages in thread
From: Christoph Lameter @ 2010-03-08 15:59 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, linux-mm, Pekka Enberg
Acked-by: Christoph Lameter <cl@linux-foundation.org>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
2010-03-08 9:21 ` Thomas Gleixner
@ 2010-03-08 16:09 ` Mel Gorman
-1 siblings, 0 replies; 28+ messages in thread
From: Mel Gorman @ 2010-03-08 16:09 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, linux-mm, Pekka Enberg, Christoph Lameter
On Mon, Mar 08, 2010 at 10:21:04AM +0100, Thomas Gleixner wrote:
> __zone_pcp_update() iterates over NR_CPUS instead of limiting the
> access to the possible cpus. This might result in access to
> uninitialized areas as the per cpu allocator only populates the per
> cpu memory for possible cpus.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Looks good.
Acked-by: Mel Gorman <mel@csn.ul.ie>
> ---
> mm/page_alloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6/mm/page_alloc.c
> ===================================================================
> --- linux-2.6.orig/mm/page_alloc.c
> +++ linux-2.6/mm/page_alloc.c
> @@ -3224,7 +3224,7 @@ static int __zone_pcp_update(void *data)
> int cpu;
> unsigned long batch = zone_batchsize(zone), flags;
>
> - for (cpu = 0; cpu < NR_CPUS; cpu++) {
> + for_each_possible_cpu(cpu) {
> struct per_cpu_pageset *pset;
> struct per_cpu_pages *pcp;
>
>
> --
> 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>
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
@ 2010-03-08 16:09 ` Mel Gorman
0 siblings, 0 replies; 28+ messages in thread
From: Mel Gorman @ 2010-03-08 16:09 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, linux-mm, Pekka Enberg, Christoph Lameter
On Mon, Mar 08, 2010 at 10:21:04AM +0100, Thomas Gleixner wrote:
> __zone_pcp_update() iterates over NR_CPUS instead of limiting the
> access to the possible cpus. This might result in access to
> uninitialized areas as the per cpu allocator only populates the per
> cpu memory for possible cpus.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Looks good.
Acked-by: Mel Gorman <mel@csn.ul.ie>
> ---
> mm/page_alloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6/mm/page_alloc.c
> ===================================================================
> --- linux-2.6.orig/mm/page_alloc.c
> +++ linux-2.6/mm/page_alloc.c
> @@ -3224,7 +3224,7 @@ static int __zone_pcp_update(void *data)
> int cpu;
> unsigned long batch = zone_batchsize(zone), flags;
>
> - for (cpu = 0; cpu < NR_CPUS; cpu++) {
> + for_each_possible_cpu(cpu) {
> struct per_cpu_pageset *pset;
> struct per_cpu_pages *pcp;
>
>
> --
> 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>
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
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>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
2010-03-08 9:21 ` Thomas Gleixner
@ 2010-03-09 6:34 ` KOSAKI Motohiro
-1 siblings, 0 replies; 28+ messages in thread
From: KOSAKI Motohiro @ 2010-03-09 6:34 UTC (permalink / raw)
To: Thomas Gleixner
Cc: kosaki.motohiro, LKML, linux-mm, Pekka Enberg, Christoph Lameter
> __zone_pcp_update() iterates over NR_CPUS instead of limiting the
> access to the possible cpus. This might result in access to
> uninitialized areas as the per cpu allocator only populates the per
> cpu memory for possible cpus.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> mm/page_alloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Looks good.
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>
> Index: linux-2.6/mm/page_alloc.c
> ===================================================================
> --- linux-2.6.orig/mm/page_alloc.c
> +++ linux-2.6/mm/page_alloc.c
> @@ -3224,7 +3224,7 @@ static int __zone_pcp_update(void *data)
> int cpu;
> unsigned long batch = zone_batchsize(zone), flags;
>
> - for (cpu = 0; cpu < NR_CPUS; cpu++) {
> + for_each_possible_cpu(cpu) {
> struct per_cpu_pageset *pset;
> struct per_cpu_pages *pcp;
>
>
> --
> 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>
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
@ 2010-03-09 6:34 ` KOSAKI Motohiro
0 siblings, 0 replies; 28+ messages in thread
From: KOSAKI Motohiro @ 2010-03-09 6:34 UTC (permalink / raw)
To: Thomas Gleixner
Cc: kosaki.motohiro, LKML, linux-mm, Pekka Enberg, Christoph Lameter
> __zone_pcp_update() iterates over NR_CPUS instead of limiting the
> access to the possible cpus. This might result in access to
> uninitialized areas as the per cpu allocator only populates the per
> cpu memory for possible cpus.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> mm/page_alloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Looks good.
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>
> Index: linux-2.6/mm/page_alloc.c
> ===================================================================
> --- linux-2.6.orig/mm/page_alloc.c
> +++ linux-2.6/mm/page_alloc.c
> @@ -3224,7 +3224,7 @@ static int __zone_pcp_update(void *data)
> int cpu;
> unsigned long batch = zone_batchsize(zone), flags;
>
> - for (cpu = 0; cpu < NR_CPUS; cpu++) {
> + for_each_possible_cpu(cpu) {
> struct per_cpu_pageset *pset;
> struct per_cpu_pages *pcp;
>
>
> --
> 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>
--
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>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
2010-03-08 9:21 ` Thomas Gleixner
@ 2010-03-09 20:22 ` Andrew Morton
-1 siblings, 0 replies; 28+ messages in thread
From: Andrew Morton @ 2010-03-09 20:22 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, linux-mm, Pekka Enberg, Christoph Lameter
On Mon, 8 Mar 2010 10:21:04 +0100 (CET)
Thomas Gleixner <tglx@linutronix.de> wrote:
> __zone_pcp_update() iterates over NR_CPUS instead of limiting the
> access to the possible cpus. This might result in access to
> uninitialized areas as the per cpu allocator only populates the per
> cpu memory for possible cpus.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> mm/page_alloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6/mm/page_alloc.c
> ===================================================================
> --- linux-2.6.orig/mm/page_alloc.c
> +++ linux-2.6/mm/page_alloc.c
> @@ -3224,7 +3224,7 @@ static int __zone_pcp_update(void *data)
> int cpu;
> unsigned long batch = zone_batchsize(zone), flags;
>
> - for (cpu = 0; cpu < NR_CPUS; cpu++) {
> + for_each_possible_cpu(cpu) {
> struct per_cpu_pageset *pset;
> struct per_cpu_pages *pcp;
>
I'm having trouble working out whether we want to backport this into
2.6.33.x or earlier. Help?
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
@ 2010-03-09 20:22 ` Andrew Morton
0 siblings, 0 replies; 28+ messages in thread
From: Andrew Morton @ 2010-03-09 20:22 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, linux-mm, Pekka Enberg, Christoph Lameter
On Mon, 8 Mar 2010 10:21:04 +0100 (CET)
Thomas Gleixner <tglx@linutronix.de> wrote:
> __zone_pcp_update() iterates over NR_CPUS instead of limiting the
> access to the possible cpus. This might result in access to
> uninitialized areas as the per cpu allocator only populates the per
> cpu memory for possible cpus.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> mm/page_alloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6/mm/page_alloc.c
> ===================================================================
> --- linux-2.6.orig/mm/page_alloc.c
> +++ linux-2.6/mm/page_alloc.c
> @@ -3224,7 +3224,7 @@ static int __zone_pcp_update(void *data)
> int cpu;
> unsigned long batch = zone_batchsize(zone), flags;
>
> - for (cpu = 0; cpu < NR_CPUS; cpu++) {
> + for_each_possible_cpu(cpu) {
> struct per_cpu_pageset *pset;
> struct per_cpu_pages *pcp;
>
I'm having trouble working out whether we want to backport this into
2.6.33.x or earlier. Help?
--
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>
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
2010-03-09 20:22 ` Andrew Morton
@ 2010-03-09 20:33 ` Christoph Lameter
-1 siblings, 0 replies; 28+ messages in thread
From: Christoph Lameter @ 2010-03-09 20:33 UTC (permalink / raw)
To: Andrew Morton; +Cc: Thomas Gleixner, LKML, linux-mm, Pekka Enberg
On Tue, 9 Mar 2010, Andrew Morton wrote:
> > __zone_pcp_update() iterates over NR_CPUS instead of limiting the
> > access to the possible cpus. This might result in access to
> > uninitialized areas as the per cpu allocator only populates the per
> > cpu memory for possible cpus.
> >
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > ---
> > mm/page_alloc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Index: linux-2.6/mm/page_alloc.c
> > ===================================================================
> > --- linux-2.6.orig/mm/page_alloc.c
> > +++ linux-2.6/mm/page_alloc.c
> > @@ -3224,7 +3224,7 @@ static int __zone_pcp_update(void *data)
> > int cpu;
> > unsigned long batch = zone_batchsize(zone), flags;
> >
> > - for (cpu = 0; cpu < NR_CPUS; cpu++) {
> > + for_each_possible_cpu(cpu) {
> > struct per_cpu_pageset *pset;
> > struct per_cpu_pages *pcp;
> >
>
> I'm having trouble working out whether we want to backport this into
> 2.6.33.x or earlier. Help?
Nope. This problem was created as a result of the dynamic allocation of
pagesets from percpu memory that went in during the merge window.
(99dcc3e5a94ed491fbef402831d8c0bbb267f995)
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
@ 2010-03-09 20:33 ` Christoph Lameter
0 siblings, 0 replies; 28+ messages in thread
From: Christoph Lameter @ 2010-03-09 20:33 UTC (permalink / raw)
To: Andrew Morton; +Cc: Thomas Gleixner, LKML, linux-mm, Pekka Enberg
On Tue, 9 Mar 2010, Andrew Morton wrote:
> > __zone_pcp_update() iterates over NR_CPUS instead of limiting the
> > access to the possible cpus. This might result in access to
> > uninitialized areas as the per cpu allocator only populates the per
> > cpu memory for possible cpus.
> >
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > ---
> > mm/page_alloc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Index: linux-2.6/mm/page_alloc.c
> > ===================================================================
> > --- linux-2.6.orig/mm/page_alloc.c
> > +++ linux-2.6/mm/page_alloc.c
> > @@ -3224,7 +3224,7 @@ static int __zone_pcp_update(void *data)
> > int cpu;
> > unsigned long batch = zone_batchsize(zone), flags;
> >
> > - for (cpu = 0; cpu < NR_CPUS; cpu++) {
> > + for_each_possible_cpu(cpu) {
> > struct per_cpu_pageset *pset;
> > struct per_cpu_pages *pcp;
> >
>
> I'm having trouble working out whether we want to backport this into
> 2.6.33.x or earlier. Help?
Nope. This problem was created as a result of the dynamic allocation of
pagesets from percpu memory that went in during the merge window.
(99dcc3e5a94ed491fbef402831d8c0bbb267f995)
--
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>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
2010-03-09 20:22 ` Andrew Morton
@ 2010-03-09 20:33 ` Robert P. J. Day
-1 siblings, 0 replies; 28+ messages in thread
From: Robert P. J. Day @ 2010-03-09 20:33 UTC (permalink / raw)
To: Andrew Morton
Cc: Thomas Gleixner, LKML, linux-mm, Pekka Enberg, Christoph Lameter
On Tue, 9 Mar 2010, Andrew Morton wrote:
> On Mon, 8 Mar 2010 10:21:04 +0100 (CET)
> Thomas Gleixner <tglx@linutronix.de> wrote:
>
> > __zone_pcp_update() iterates over NR_CPUS instead of limiting the
> > access to the possible cpus. This might result in access to
> > uninitialized areas as the per cpu allocator only populates the per
> > cpu memory for possible cpus.
> >
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > ---
> > mm/page_alloc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Index: linux-2.6/mm/page_alloc.c
> > ===================================================================
> > --- linux-2.6.orig/mm/page_alloc.c
> > +++ linux-2.6/mm/page_alloc.c
> > @@ -3224,7 +3224,7 @@ static int __zone_pcp_update(void *data)
> > int cpu;
> > unsigned long batch = zone_batchsize(zone), flags;
> >
> > - for (cpu = 0; cpu < NR_CPUS; cpu++) {
> > + for_each_possible_cpu(cpu) {
> > struct per_cpu_pageset *pset;
> > struct per_cpu_pages *pcp;
>
> I'm having trouble working out whether we want to backport this into
> 2.6.33.x or earlier. Help?
given the above aesthetic mod, shouldn't that same change be applied
to *all* explicit loops of that form? after all, checkpatch.pl warns
against it:
=====
# use of NR_CPUS is usually wrong
# ignore definitions of NR_CPUS and usage to define arrays as likely right
if ($line =~ /\bNR_CPUS\b/ &&
$line !~ /^.\s*\s*#\s*if\b.*\bNR_CPUS\b/ &&
$line !~ /^.\s*\s*#\s*define\b.*\bNR_CPUS\b/ &&
$line !~ /^.\s*$Declare\s.*\[[^\]]*NR_CPUS[^\]]*\]/ &&
$line !~ /\[[^\]]*\.\.\.[^\]]*NR_CPUS[^\]]*\]/ &&
$line !~ /\[[^\]]*NR_CPUS[^\]]*\.\.\.[^\]]*\]/)
{
WARN("usage of NR_CPUS is often wrong - consider using cpu_possible(), num_possible_cpus(), for_each_possible_cpu(), etc\n" . $herecurr);
}
=====
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
@ 2010-03-09 20:33 ` Robert P. J. Day
0 siblings, 0 replies; 28+ messages in thread
From: Robert P. J. Day @ 2010-03-09 20:33 UTC (permalink / raw)
To: Andrew Morton
Cc: Thomas Gleixner, LKML, linux-mm, Pekka Enberg, Christoph Lameter
On Tue, 9 Mar 2010, Andrew Morton wrote:
> On Mon, 8 Mar 2010 10:21:04 +0100 (CET)
> Thomas Gleixner <tglx@linutronix.de> wrote:
>
> > __zone_pcp_update() iterates over NR_CPUS instead of limiting the
> > access to the possible cpus. This might result in access to
> > uninitialized areas as the per cpu allocator only populates the per
> > cpu memory for possible cpus.
> >
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > ---
> > mm/page_alloc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Index: linux-2.6/mm/page_alloc.c
> > ===================================================================
> > --- linux-2.6.orig/mm/page_alloc.c
> > +++ linux-2.6/mm/page_alloc.c
> > @@ -3224,7 +3224,7 @@ static int __zone_pcp_update(void *data)
> > int cpu;
> > unsigned long batch = zone_batchsize(zone), flags;
> >
> > - for (cpu = 0; cpu < NR_CPUS; cpu++) {
> > + for_each_possible_cpu(cpu) {
> > struct per_cpu_pageset *pset;
> > struct per_cpu_pages *pcp;
>
> I'm having trouble working out whether we want to backport this into
> 2.6.33.x or earlier. Help?
given the above aesthetic mod, shouldn't that same change be applied
to *all* explicit loops of that form? after all, checkpatch.pl warns
against it:
=====
# use of NR_CPUS is usually wrong
# ignore definitions of NR_CPUS and usage to define arrays as likely right
if ($line =~ /\bNR_CPUS\b/ &&
$line !~ /^.\s*\s*#\s*if\b.*\bNR_CPUS\b/ &&
$line !~ /^.\s*\s*#\s*define\b.*\bNR_CPUS\b/ &&
$line !~ /^.\s*$Declare\s.*\[[^\]]*NR_CPUS[^\]]*\]/ &&
$line !~ /\[[^\]]*\.\.\.[^\]]*NR_CPUS[^\]]*\]/ &&
$line !~ /\[[^\]]*NR_CPUS[^\]]*\.\.\.[^\]]*\]/)
{
WARN("usage of NR_CPUS is often wrong - consider using cpu_possible(), num_possible_cpus(), for_each_possible_cpu(), etc\n" . $herecurr);
}
=====
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
--
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>
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
2010-03-09 20:33 ` Robert P. J. Day
@ 2010-03-09 20:55 ` Christoph Lameter
-1 siblings, 0 replies; 28+ messages in thread
From: Christoph Lameter @ 2010-03-09 20:55 UTC (permalink / raw)
To: Robert P. J. Day
Cc: Andrew Morton, Thomas Gleixner, LKML, linux-mm, Pekka Enberg
On Tue, 9 Mar 2010, Robert P. J. Day wrote:
> > I'm having trouble working out whether we want to backport this into
> > 2.6.33.x or earlier. Help?
>
> given the above aesthetic mod, shouldn't that same change be applied
> to *all* explicit loops of that form? after all, checkpatch.pl warns
> against it:
The number of NR_CPUS should be significantly less after the percpu
rework. Would you audit the kernel for NR_CPUS use?
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
@ 2010-03-09 20:55 ` Christoph Lameter
0 siblings, 0 replies; 28+ messages in thread
From: Christoph Lameter @ 2010-03-09 20:55 UTC (permalink / raw)
To: Robert P. J. Day
Cc: Andrew Morton, Thomas Gleixner, LKML, linux-mm, Pekka Enberg
On Tue, 9 Mar 2010, Robert P. J. Day wrote:
> > I'm having trouble working out whether we want to backport this into
> > 2.6.33.x or earlier. Help?
>
> given the above aesthetic mod, shouldn't that same change be applied
> to *all* explicit loops of that form? after all, checkpatch.pl warns
> against it:
The number of NR_CPUS should be significantly less after the percpu
rework. Would you audit the kernel for NR_CPUS use?
--
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>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
2010-03-09 20:55 ` Christoph Lameter
@ 2010-03-09 21:02 ` Robert P. J. Day
-1 siblings, 0 replies; 28+ messages in thread
From: Robert P. J. Day @ 2010-03-09 21:02 UTC (permalink / raw)
To: Christoph Lameter
Cc: Andrew Morton, Thomas Gleixner, LKML, linux-mm, Pekka Enberg
On Tue, 9 Mar 2010, Christoph Lameter wrote:
> On Tue, 9 Mar 2010, Robert P. J. Day wrote:
>
> > > I'm having trouble working out whether we want to backport this into
> > > 2.6.33.x or earlier. Help?
> >
> > given the above aesthetic mod, shouldn't that same change be
> > applied to *all* explicit loops of that form? after all,
> > checkpatch.pl warns against it:
>
> The number of NR_CPUS should be significantly less after the percpu
> rework. Would you audit the kernel for NR_CPUS use?
i just did a simple grep for the obvious pattern:
$ grep -r "for.*NR_CPUS" *
arch/sparc/mm/init_64.c: for (i = 0; i < NR_CPUS; i++)
arch/sparc/kernel/sun4d_smp.c: for (i = 0; i < NR_CPUS; i++) {
arch/sparc/kernel/traps_64.c: for (i = 0; i < NR_CPUS; i++) {
... etc etc ...
most of the occurrences are under arch/. as you say, after the
rework, most of those should be replaceable.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: mm: Do not iterate over NR_CPUS in __zone_pcp_update()
@ 2010-03-09 21:02 ` Robert P. J. Day
0 siblings, 0 replies; 28+ messages in thread
From: Robert P. J. Day @ 2010-03-09 21:02 UTC (permalink / raw)
To: Christoph Lameter
Cc: Andrew Morton, Thomas Gleixner, LKML, linux-mm, Pekka Enberg
On Tue, 9 Mar 2010, Christoph Lameter wrote:
> On Tue, 9 Mar 2010, Robert P. J. Day wrote:
>
> > > I'm having trouble working out whether we want to backport this into
> > > 2.6.33.x or earlier. Help?
> >
> > given the above aesthetic mod, shouldn't that same change be
> > applied to *all* explicit loops of that form? after all,
> > checkpatch.pl warns against it:
>
> The number of NR_CPUS should be significantly less after the percpu
> rework. Would you audit the kernel for NR_CPUS use?
i just did a simple grep for the obvious pattern:
$ grep -r "for.*NR_CPUS" *
arch/sparc/mm/init_64.c: for (i = 0; i < NR_CPUS; i++)
arch/sparc/kernel/sun4d_smp.c: for (i = 0; i < NR_CPUS; i++) {
arch/sparc/kernel/traps_64.c: for (i = 0; i < NR_CPUS; i++) {
... etc etc ...
most of the occurrences are under arch/. as you say, after the
rework, most of those should be replaceable.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
--
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>
^ permalink raw reply [flat|nested] 28+ messages in thread