All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tang Chen <tangchen@cn.fujitsu.com>
To: wency@cn.fujitsu.com
Cc: x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-ia64@vger.kernel.org, cmetcalf@tilera.com,
	sparclinux@vger.kernel.org, rientjes@google.com,
	liuj97@gmail.com, len.brown@intel.com, benh@kernel.crashing.org,
	paulus@samba.org, cl@linux.com, minchan.kim@gmail.com,
	akpm@linux-foundation.org, kosaki.motohiro@jp.fujitsu.com,
	isimatu.yasuaki@jp.fujitsu.com
Subject: [PATCH] Update start_pfn in zone and pg_data when spanned_pages == 0.
Date: Wed, 07 Nov 2012 07:40:44 +0000	[thread overview]
Message-ID: <509A107C.9050702@cn.fujitsu.com> (raw)
In-Reply-To: <1350988250-31294-11-git-send-email-wency@cn.fujitsu.com>

On 10/23/2012 06:30 PM, wency@cn.fujitsu.com wrote:
> From: Yasuaki Ishimatsu<isimatu.yasuaki@jp.fujitsu.com>
......
> +	/* The zone has no valid section */
> +	zone->zone_start_pfn = 0;
> +	zone->spanned_pages = 0;
> +	zone_span_writeunlock(zone);
> +}
> +
> +static void shrink_pgdat_span(struct pglist_data *pgdat,
> +			      unsigned long start_pfn, unsigned long end_pfn)
> +{
......
> +	/* The pgdat has no valid section */
> +	pgdat->node_start_pfn = 0;
> +	pgdat->node_spanned_pages = 0;
> +}

Hi,

If we hot-remove memory only and leave the cpus alive, the corresponding
node will not be removed. But the node_start_pfn and node_spanned_pages
in pg_data will be reset to 0. In this case, when we hot-add the memory
back next time, the node_start_pfn will always be 0 because no pfn is less
than 0. After that, if we hot-remove the memory again, it will cause kernel
panic in function find_biggest_section_pfn() when it tries to scan all 
the pfns.

The zone will also have the same problem.

This patch sets start_pfn to the start_pfn of the section being added when
spanned_pages of the zone or pg_data is 0.

---How to reproduce---

1. hot-add a container with some memory and cpus;
2. hot-remove the container's memory, and leave cpus there;
3. hot-add these memory again;
4. hot-remove them again;

then, the kernel will panic.

---Call trace---

[10530.646285] BUG: unable to handle kernel paging request at 
00000fff82a8cc38
[10530.729670] IP: [<ffffffff811c0d55>] find_biggest_section_pfn+0xe5/0x180
......
[10533.064975] Call Trace:
[10533.094162]  [<ffffffff811c0fcf>] ? __remove_zone+0x2f/0x1b0
[10533.161757]  [<ffffffff811c1124>] __remove_zone+0x184/0x1b0
[10533.228318]  [<ffffffff811c11dc>] __remove_section+0x8c/0xb0
[10533.295916]  [<ffffffff811c12e7>] __remove_pages+0xe7/0x120
[10533.362476]  [<ffffffff81654f7c>] arch_remove_memory+0x2c/0x80
[10533.432151]  [<ffffffff81655bb6>] remove_memory+0x56/0x90
[10533.496633]  [<ffffffff813da0c8>] 
acpi_memory_device_remove_memory+0x48/0x73
[10533.580846]  [<ffffffff813da55a>] acpi_memory_device_notify+0x153/0x274
[10533.659865]  [<ffffffff813a63cf>] ? acpi_bus_get_device+0x2f/0x77
[10533.732653]  [<ffffffff813a6589>] ? acpi_bus_notify+0xb5/0xec
[10533.801291]  [<ffffffff813b6786>] acpi_ev_notify_dispatch+0x41/0x5f
[10533.876156]  [<ffffffff813a3867>] acpi_os_execute_deferred+0x27/0x34
[10533.952062]  [<ffffffff81090589>] process_one_work+0x219/0x680
[10534.021736]  [<ffffffff81090528>] ? process_one_work+0x1b8/0x680
[10534.093488]  [<ffffffff813a3840>] ? 
acpi_os_wait_events_complete+0x23/0x23
[10534.175622]  [<ffffffff810923be>] worker_thread+0x12e/0x320
[10534.242181]  [<ffffffff81092290>] ? manage_workers+0x110/0x110
[10534.311855]  [<ffffffff81098396>] kthread+0xc6/0xd0
[10534.370111]  [<ffffffff8167c7c4>] kernel_thread_helper+0x4/0x10
[10534.440824]  [<ffffffff81672230>] ? retint_restore_args+0x13/0x13
[10534.513612]  [<ffffffff810982d0>] ? __init_kthread_worker+0x70/0x70
[10534.588480]  [<ffffffff8167c7c0>] ? gs_change+0x13/0x13
......
[10535.045543] ---[ end trace 96d845dbf33fee11 ]---


Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
  mm/memory_hotplug.c |    4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 56b758a..4aa313c 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -212,7 +212,7 @@ static void grow_zone_span(struct zone *zone, 
unsigned long start_pfn,
         zone_span_writelock(zone);

         old_zone_end_pfn = zone->zone_start_pfn + zone->spanned_pages;
-       if (start_pfn < zone->zone_start_pfn)
+       if (!zone->spanned_pages || start_pfn < zone->zone_start_pfn)
                 zone->zone_start_pfn = start_pfn;

         zone->spanned_pages = max(old_zone_end_pfn, end_pfn) -
@@ -227,7 +227,7 @@ static void grow_pgdat_span(struct pglist_data 
*pgdat, unsigned long start_pfn,
         unsigned long old_pgdat_end_pfn                  pgdat->node_start_pfn + pgdat->node_spanned_pages;

-       if (start_pfn < pgdat->node_start_pfn)
+       if (!pgdat->node_spanned_pages || start_pfn < pgdat->node_start_pfn)
                 pgdat->node_start_pfn = start_pfn;

         pgdat->node_spanned_pages = max(old_pgdat_end_pfn, end_pfn) -
-- 
1.7.10.1


WARNING: multiple messages have this Message-ID (diff)
From: Tang Chen <tangchen@cn.fujitsu.com>
To: wency@cn.fujitsu.com
Cc: x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-ia64@vger.kernel.org, cmetcalf@tilera.com,
	sparclinux@vger.kernel.org, rientjes@google.com,
	liuj97@gmail.com, len.brown@intel.com, benh@kernel.crashing.org,
	paulus@samba.org, cl@linux.com, minchan.kim@gmail.com,
	akpm@linux-foundation.org, kosaki.motohiro@jp.fujitsu.com,
	isimatu.yasuaki@jp.fujitsu.com
Subject: [PATCH] Update start_pfn in zone and pg_data when spanned_pages == 0.
Date: Wed, 07 Nov 2012 15:40:44 +0800	[thread overview]
Message-ID: <509A107C.9050702@cn.fujitsu.com> (raw)
In-Reply-To: <1350988250-31294-11-git-send-email-wency@cn.fujitsu.com>

On 10/23/2012 06:30 PM, wency@cn.fujitsu.com wrote:
> From: Yasuaki Ishimatsu<isimatu.yasuaki@jp.fujitsu.com>
......
> +	/* The zone has no valid section */
> +	zone->zone_start_pfn = 0;
> +	zone->spanned_pages = 0;
> +	zone_span_writeunlock(zone);
> +}
> +
> +static void shrink_pgdat_span(struct pglist_data *pgdat,
> +			      unsigned long start_pfn, unsigned long end_pfn)
> +{
......
> +	/* The pgdat has no valid section */
> +	pgdat->node_start_pfn = 0;
> +	pgdat->node_spanned_pages = 0;
> +}

Hi,

If we hot-remove memory only and leave the cpus alive, the corresponding
node will not be removed. But the node_start_pfn and node_spanned_pages
in pg_data will be reset to 0. In this case, when we hot-add the memory
back next time, the node_start_pfn will always be 0 because no pfn is less
than 0. After that, if we hot-remove the memory again, it will cause kernel
panic in function find_biggest_section_pfn() when it tries to scan all 
the pfns.

The zone will also have the same problem.

This patch sets start_pfn to the start_pfn of the section being added when
spanned_pages of the zone or pg_data is 0.

---How to reproduce---

1. hot-add a container with some memory and cpus;
2. hot-remove the container's memory, and leave cpus there;
3. hot-add these memory again;
4. hot-remove them again;

then, the kernel will panic.

---Call trace---

[10530.646285] BUG: unable to handle kernel paging request at 
00000fff82a8cc38
[10530.729670] IP: [<ffffffff811c0d55>] find_biggest_section_pfn+0xe5/0x180
......
[10533.064975] Call Trace:
[10533.094162]  [<ffffffff811c0fcf>] ? __remove_zone+0x2f/0x1b0
[10533.161757]  [<ffffffff811c1124>] __remove_zone+0x184/0x1b0
[10533.228318]  [<ffffffff811c11dc>] __remove_section+0x8c/0xb0
[10533.295916]  [<ffffffff811c12e7>] __remove_pages+0xe7/0x120
[10533.362476]  [<ffffffff81654f7c>] arch_remove_memory+0x2c/0x80
[10533.432151]  [<ffffffff81655bb6>] remove_memory+0x56/0x90
[10533.496633]  [<ffffffff813da0c8>] 
acpi_memory_device_remove_memory+0x48/0x73
[10533.580846]  [<ffffffff813da55a>] acpi_memory_device_notify+0x153/0x274
[10533.659865]  [<ffffffff813a63cf>] ? acpi_bus_get_device+0x2f/0x77
[10533.732653]  [<ffffffff813a6589>] ? acpi_bus_notify+0xb5/0xec
[10533.801291]  [<ffffffff813b6786>] acpi_ev_notify_dispatch+0x41/0x5f
[10533.876156]  [<ffffffff813a3867>] acpi_os_execute_deferred+0x27/0x34
[10533.952062]  [<ffffffff81090589>] process_one_work+0x219/0x680
[10534.021736]  [<ffffffff81090528>] ? process_one_work+0x1b8/0x680
[10534.093488]  [<ffffffff813a3840>] ? 
acpi_os_wait_events_complete+0x23/0x23
[10534.175622]  [<ffffffff810923be>] worker_thread+0x12e/0x320
[10534.242181]  [<ffffffff81092290>] ? manage_workers+0x110/0x110
[10534.311855]  [<ffffffff81098396>] kthread+0xc6/0xd0
[10534.370111]  [<ffffffff8167c7c4>] kernel_thread_helper+0x4/0x10
[10534.440824]  [<ffffffff81672230>] ? retint_restore_args+0x13/0x13
[10534.513612]  [<ffffffff810982d0>] ? __init_kthread_worker+0x70/0x70
[10534.588480]  [<ffffffff8167c7c0>] ? gs_change+0x13/0x13
......
[10535.045543] ---[ end trace 96d845dbf33fee11 ]---


Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
  mm/memory_hotplug.c |    4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 56b758a..4aa313c 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -212,7 +212,7 @@ static void grow_zone_span(struct zone *zone, 
unsigned long start_pfn,
         zone_span_writelock(zone);

         old_zone_end_pfn = zone->zone_start_pfn + zone->spanned_pages;
-       if (start_pfn < zone->zone_start_pfn)
+       if (!zone->spanned_pages || start_pfn < zone->zone_start_pfn)
                 zone->zone_start_pfn = start_pfn;

         zone->spanned_pages = max(old_zone_end_pfn, end_pfn) -
@@ -227,7 +227,7 @@ static void grow_pgdat_span(struct pglist_data 
*pgdat, unsigned long start_pfn,
         unsigned long old_pgdat_end_pfn =
                 pgdat->node_start_pfn + pgdat->node_spanned_pages;

-       if (start_pfn < pgdat->node_start_pfn)
+       if (!pgdat->node_spanned_pages || start_pfn < pgdat->node_start_pfn)
                 pgdat->node_start_pfn = start_pfn;

         pgdat->node_spanned_pages = max(old_pgdat_end_pfn, end_pfn) -
-- 
1.7.10.1


WARNING: multiple messages have this Message-ID (diff)
From: Tang Chen <tangchen@cn.fujitsu.com>
To: wency@cn.fujitsu.com
Cc: x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-ia64@vger.kernel.org, cmetcalf@tilera.com,
	sparclinux@vger.kernel.org, rientjes@google.com,
	liuj97@gmail.com, len.brown@intel.com, benh@kernel.crashing.org,
	paulus@samba.org, cl@linux.com, minchan.kim@gmail.com,
	akpm@linux-foundation.org, kosaki.motohiro@jp.fujitsu.com,
	isimatu.yasuaki@jp.fujitsu.com
Subject: [PATCH] Update start_pfn in zone and pg_data when spanned_pages == 0.
Date: Wed, 07 Nov 2012 15:40:44 +0800	[thread overview]
Message-ID: <509A107C.9050702@cn.fujitsu.com> (raw)
In-Reply-To: <1350988250-31294-11-git-send-email-wency@cn.fujitsu.com>

On 10/23/2012 06:30 PM, wency@cn.fujitsu.com wrote:
> From: Yasuaki Ishimatsu<isimatu.yasuaki@jp.fujitsu.com>
......
> +	/* The zone has no valid section */
> +	zone->zone_start_pfn = 0;
> +	zone->spanned_pages = 0;
> +	zone_span_writeunlock(zone);
> +}
> +
> +static void shrink_pgdat_span(struct pglist_data *pgdat,
> +			      unsigned long start_pfn, unsigned long end_pfn)
> +{
......
> +	/* The pgdat has no valid section */
> +	pgdat->node_start_pfn = 0;
> +	pgdat->node_spanned_pages = 0;
> +}

Hi,

If we hot-remove memory only and leave the cpus alive, the corresponding
node will not be removed. But the node_start_pfn and node_spanned_pages
in pg_data will be reset to 0. In this case, when we hot-add the memory
back next time, the node_start_pfn will always be 0 because no pfn is less
than 0. After that, if we hot-remove the memory again, it will cause kernel
panic in function find_biggest_section_pfn() when it tries to scan all 
the pfns.

The zone will also have the same problem.

This patch sets start_pfn to the start_pfn of the section being added when
spanned_pages of the zone or pg_data is 0.

---How to reproduce---

1. hot-add a container with some memory and cpus;
2. hot-remove the container's memory, and leave cpus there;
3. hot-add these memory again;
4. hot-remove them again;

then, the kernel will panic.

---Call trace---

[10530.646285] BUG: unable to handle kernel paging request at 
00000fff82a8cc38
[10530.729670] IP: [<ffffffff811c0d55>] find_biggest_section_pfn+0xe5/0x180
......
[10533.064975] Call Trace:
[10533.094162]  [<ffffffff811c0fcf>] ? __remove_zone+0x2f/0x1b0
[10533.161757]  [<ffffffff811c1124>] __remove_zone+0x184/0x1b0
[10533.228318]  [<ffffffff811c11dc>] __remove_section+0x8c/0xb0
[10533.295916]  [<ffffffff811c12e7>] __remove_pages+0xe7/0x120
[10533.362476]  [<ffffffff81654f7c>] arch_remove_memory+0x2c/0x80
[10533.432151]  [<ffffffff81655bb6>] remove_memory+0x56/0x90
[10533.496633]  [<ffffffff813da0c8>] 
acpi_memory_device_remove_memory+0x48/0x73
[10533.580846]  [<ffffffff813da55a>] acpi_memory_device_notify+0x153/0x274
[10533.659865]  [<ffffffff813a63cf>] ? acpi_bus_get_device+0x2f/0x77
[10533.732653]  [<ffffffff813a6589>] ? acpi_bus_notify+0xb5/0xec
[10533.801291]  [<ffffffff813b6786>] acpi_ev_notify_dispatch+0x41/0x5f
[10533.876156]  [<ffffffff813a3867>] acpi_os_execute_deferred+0x27/0x34
[10533.952062]  [<ffffffff81090589>] process_one_work+0x219/0x680
[10534.021736]  [<ffffffff81090528>] ? process_one_work+0x1b8/0x680
[10534.093488]  [<ffffffff813a3840>] ? 
acpi_os_wait_events_complete+0x23/0x23
[10534.175622]  [<ffffffff810923be>] worker_thread+0x12e/0x320
[10534.242181]  [<ffffffff81092290>] ? manage_workers+0x110/0x110
[10534.311855]  [<ffffffff81098396>] kthread+0xc6/0xd0
[10534.370111]  [<ffffffff8167c7c4>] kernel_thread_helper+0x4/0x10
[10534.440824]  [<ffffffff81672230>] ? retint_restore_args+0x13/0x13
[10534.513612]  [<ffffffff810982d0>] ? __init_kthread_worker+0x70/0x70
[10534.588480]  [<ffffffff8167c7c0>] ? gs_change+0x13/0x13
......
[10535.045543] ---[ end trace 96d845dbf33fee11 ]---


Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
  mm/memory_hotplug.c |    4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 56b758a..4aa313c 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -212,7 +212,7 @@ static void grow_zone_span(struct zone *zone, 
unsigned long start_pfn,
         zone_span_writelock(zone);

         old_zone_end_pfn = zone->zone_start_pfn + zone->spanned_pages;
-       if (start_pfn < zone->zone_start_pfn)
+       if (!zone->spanned_pages || start_pfn < zone->zone_start_pfn)
                 zone->zone_start_pfn = start_pfn;

         zone->spanned_pages = max(old_zone_end_pfn, end_pfn) -
@@ -227,7 +227,7 @@ static void grow_pgdat_span(struct pglist_data 
*pgdat, unsigned long start_pfn,
         unsigned long old_pgdat_end_pfn =
                 pgdat->node_start_pfn + pgdat->node_spanned_pages;

-       if (start_pfn < pgdat->node_start_pfn)
+       if (!pgdat->node_spanned_pages || start_pfn < pgdat->node_start_pfn)
                 pgdat->node_start_pfn = start_pfn;

         pgdat->node_spanned_pages = max(old_pgdat_end_pfn, end_pfn) -
-- 
1.7.10.1

--
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: Tang Chen <tangchen@cn.fujitsu.com>
To: wency@cn.fujitsu.com
Cc: linux-s390@vger.kernel.org, linux-ia64@vger.kernel.org,
	len.brown@intel.com, linux-acpi@vger.kernel.org,
	linux-sh@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, cmetcalf@tilera.com,
	linux-mm@kvack.org, isimatu.yasuaki@jp.fujitsu.com,
	paulus@samba.org, minchan.kim@gmail.com,
	kosaki.motohiro@jp.fujitsu.com, rientjes@google.com,
	sparclinux@vger.kernel.org, cl@linux.com,
	linuxppc-dev@lists.ozlabs.org, akpm@linux-foundation.org,
	liuj97@gmail.com
Subject: [PATCH] Update start_pfn in zone and pg_data when spanned_pages == 0.
Date: Wed, 07 Nov 2012 15:40:44 +0800	[thread overview]
Message-ID: <509A107C.9050702@cn.fujitsu.com> (raw)
In-Reply-To: <1350988250-31294-11-git-send-email-wency@cn.fujitsu.com>

On 10/23/2012 06:30 PM, wency@cn.fujitsu.com wrote:
> From: Yasuaki Ishimatsu<isimatu.yasuaki@jp.fujitsu.com>
......
> +	/* The zone has no valid section */
> +	zone->zone_start_pfn = 0;
> +	zone->spanned_pages = 0;
> +	zone_span_writeunlock(zone);
> +}
> +
> +static void shrink_pgdat_span(struct pglist_data *pgdat,
> +			      unsigned long start_pfn, unsigned long end_pfn)
> +{
......
> +	/* The pgdat has no valid section */
> +	pgdat->node_start_pfn = 0;
> +	pgdat->node_spanned_pages = 0;
> +}

Hi,

If we hot-remove memory only and leave the cpus alive, the corresponding
node will not be removed. But the node_start_pfn and node_spanned_pages
in pg_data will be reset to 0. In this case, when we hot-add the memory
back next time, the node_start_pfn will always be 0 because no pfn is less
than 0. After that, if we hot-remove the memory again, it will cause kernel
panic in function find_biggest_section_pfn() when it tries to scan all 
the pfns.

The zone will also have the same problem.

This patch sets start_pfn to the start_pfn of the section being added when
spanned_pages of the zone or pg_data is 0.

---How to reproduce---

1. hot-add a container with some memory and cpus;
2. hot-remove the container's memory, and leave cpus there;
3. hot-add these memory again;
4. hot-remove them again;

then, the kernel will panic.

---Call trace---

[10530.646285] BUG: unable to handle kernel paging request at 
00000fff82a8cc38
[10530.729670] IP: [<ffffffff811c0d55>] find_biggest_section_pfn+0xe5/0x180
......
[10533.064975] Call Trace:
[10533.094162]  [<ffffffff811c0fcf>] ? __remove_zone+0x2f/0x1b0
[10533.161757]  [<ffffffff811c1124>] __remove_zone+0x184/0x1b0
[10533.228318]  [<ffffffff811c11dc>] __remove_section+0x8c/0xb0
[10533.295916]  [<ffffffff811c12e7>] __remove_pages+0xe7/0x120
[10533.362476]  [<ffffffff81654f7c>] arch_remove_memory+0x2c/0x80
[10533.432151]  [<ffffffff81655bb6>] remove_memory+0x56/0x90
[10533.496633]  [<ffffffff813da0c8>] 
acpi_memory_device_remove_memory+0x48/0x73
[10533.580846]  [<ffffffff813da55a>] acpi_memory_device_notify+0x153/0x274
[10533.659865]  [<ffffffff813a63cf>] ? acpi_bus_get_device+0x2f/0x77
[10533.732653]  [<ffffffff813a6589>] ? acpi_bus_notify+0xb5/0xec
[10533.801291]  [<ffffffff813b6786>] acpi_ev_notify_dispatch+0x41/0x5f
[10533.876156]  [<ffffffff813a3867>] acpi_os_execute_deferred+0x27/0x34
[10533.952062]  [<ffffffff81090589>] process_one_work+0x219/0x680
[10534.021736]  [<ffffffff81090528>] ? process_one_work+0x1b8/0x680
[10534.093488]  [<ffffffff813a3840>] ? 
acpi_os_wait_events_complete+0x23/0x23
[10534.175622]  [<ffffffff810923be>] worker_thread+0x12e/0x320
[10534.242181]  [<ffffffff81092290>] ? manage_workers+0x110/0x110
[10534.311855]  [<ffffffff81098396>] kthread+0xc6/0xd0
[10534.370111]  [<ffffffff8167c7c4>] kernel_thread_helper+0x4/0x10
[10534.440824]  [<ffffffff81672230>] ? retint_restore_args+0x13/0x13
[10534.513612]  [<ffffffff810982d0>] ? __init_kthread_worker+0x70/0x70
[10534.588480]  [<ffffffff8167c7c0>] ? gs_change+0x13/0x13
......
[10535.045543] ---[ end trace 96d845dbf33fee11 ]---


Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
  mm/memory_hotplug.c |    4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 56b758a..4aa313c 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -212,7 +212,7 @@ static void grow_zone_span(struct zone *zone, 
unsigned long start_pfn,
         zone_span_writelock(zone);

         old_zone_end_pfn = zone->zone_start_pfn + zone->spanned_pages;
-       if (start_pfn < zone->zone_start_pfn)
+       if (!zone->spanned_pages || start_pfn < zone->zone_start_pfn)
                 zone->zone_start_pfn = start_pfn;

         zone->spanned_pages = max(old_zone_end_pfn, end_pfn) -
@@ -227,7 +227,7 @@ static void grow_pgdat_span(struct pglist_data 
*pgdat, unsigned long start_pfn,
         unsigned long old_pgdat_end_pfn =
                 pgdat->node_start_pfn + pgdat->node_spanned_pages;

-       if (start_pfn < pgdat->node_start_pfn)
+       if (!pgdat->node_spanned_pages || start_pfn < pgdat->node_start_pfn)
                 pgdat->node_start_pfn = start_pfn;

         pgdat->node_spanned_pages = max(old_pgdat_end_pfn, end_pfn) -
-- 
1.7.10.1

  parent reply	other threads:[~2012-11-07  7:40 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-23 10:30 [PATCH v2 00/12] memory-hotplug: hot-remove physical memory wency
2012-10-23 10:30 ` wency
2012-10-23 10:30 ` wency
2012-10-23 10:30 ` wency
2012-10-23 10:30 ` Ni zhan Chen
2012-10-23 10:30   ` Ni zhan Chen
2012-10-23 10:30   ` Ni zhan Chen
2012-10-23 10:30   ` Ni zhan Chen
2012-10-23 10:39   ` Wen Congyang
2012-10-23 10:39     ` Wen Congyang
2012-10-23 10:39     ` Wen Congyang
2012-10-23 10:39     ` Wen Congyang
2012-10-23 10:30 ` [PATCH v2 01/12] memory-hotplug: try to offline the memory twice to avoid dependence wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-23 10:30 ` [PATCH v2 02/12] memory-hotplug: check whether all memory blocks are offlined or not when removing m wency
2012-10-23 10:30   ` [PATCH v2 02/12] memory-hotplug: check whether all memory blocks are offlined or not when removing memory wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-23 10:30 ` [PATCH v2 03/12] memory-hotplug: remove redundant codes wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-23 10:30 ` [PATCH v2 04/12] memory-hotplug: remove /sys/firmware/memmap/X sysfs wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-23 10:30 ` [PATCH v2 05/12] memory-hotplug: introduce new function arch_remove_memory() for removing page table wency
2012-10-23 10:30   ` [PATCH v2 05/12] memory-hotplug: introduce new function arch_remove_memory() for removing page table depends on architecture wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-23 10:30 ` [PATCH v2 06/12] memory-hotplug: unregister memory section on SPARSEMEM_VMEMMAP wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-23 10:30 ` [PATCH v2 07/12] memory-hotplug: implement register_page_bootmem_info_section of sparse-vmemmap wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-23 10:30 ` [PATCH v2 08/12] memory-hotplug: remove memmap " wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-23 10:30 ` [PATCH v2 09/12] memory-hotplug: remove page table of x86_64 architecture wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-23 10:30 ` [PATCH v2 10/12] memory-hotplug: memory_hotplug: clear zone when removing the memory wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-29 15:34   ` Jianguo Wu
2012-10-29 15:34     ` Jianguo Wu
2012-10-29 15:34     ` Jianguo Wu
2012-10-29 15:34     ` Jianguo Wu
2012-10-30  1:50     ` Wen Congyang
2012-10-30  1:50       ` Wen Congyang
2012-10-30  1:50       ` Wen Congyang
2012-10-30  1:50       ` Wen Congyang
2012-11-07  7:40   ` Tang Chen [this message]
2012-11-07  7:40     ` [PATCH] Update start_pfn in zone and pg_data when spanned_pages == 0 Tang Chen
2012-11-07  7:40     ` Tang Chen
2012-11-07  7:40     ` Tang Chen
2012-10-23 10:30 ` [PATCH v2 11/12] memory-hotplug: remove sysfs file of node wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-23 10:30 ` [PATCH v2 12/12] memory-hotplug: free node_data when a node is offlined wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency
2012-10-23 10:30   ` wency

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=509A107C.9050702@cn.fujitsu.com \
    --to=tangchen@cn.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=cl@linux.com \
    --cc=cmetcalf@tilera.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=liuj97@gmail.com \
    --cc=minchan.kim@gmail.com \
    --cc=paulus@samba.org \
    --cc=rientjes@google.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=wency@cn.fujitsu.com \
    --cc=x86@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.