[PATCH v2] kexec: add cond_resched into kimage_alloc_crash_control_pages

2016-12-07 Thread zhongjiang 
From: zhong jiang 

A soft lookup will occur when I run trinity in syscall kexec_load.
the corresponding stack information is as follows.

[  237.235937] BUG: soft lockup - CPU#6 stuck for 22s! [trinity-c6:13859]
[  237.242699] Kernel panic - not syncing: softlockup: hung tasks
[  237.248573] CPU: 6 PID: 13859 Comm: trinity-c6 Tainted: G   O L 
V---   3.10.0-327.28.3.35.zhongjiang.x86_64 #1
[  237.259984] Hardware name: Huawei Technologies Co., Ltd. Tecal BH622 
V2/BC01SRSA0, BIOS RMIBV386 06/30/2014
[  237.269752]  8187626b 18cfde31 88184c803e18 
81638f16
[  237.277471]  88184c803e98 8163278f 0008 
88184c803ea8
[  237.285190]  88184c803e48 18cfde31 88184c803e67 

[  237.292909] Call Trace:
[  237.295404][] dump_stack+0x19/0x1b
[  237.301352]  [] panic+0xd8/0x214
[  237.306196]  [] watchdog_timer_fn+0x1cc/0x1e0
[  237.312157]  [] ? watchdog_enable+0xc0/0xc0
[  237.317955]  [] __hrtimer_run_queues+0xd2/0x260
[  237.324087]  [] hrtimer_interrupt+0xb0/0x1e0
[  237.329963]  [] ? call_softirq+0x1c/0x30
[  237.335500]  [] local_apic_timer_interrupt+0x37/0x60
[  237.342228]  [] smp_apic_timer_interrupt+0x3f/0x60
[  237.348771]  [] apic_timer_interrupt+0x6d/0x80
[  237.354967][] ? 
kimage_alloc_control_pages+0x80/0x270
[  237.362875]  [] ? kmem_cache_alloc_trace+0x1ce/0x1f0
[  237.369592]  [] ? do_kimage_alloc_init+0x1f/0x90
[  237.375992]  [] kimage_alloc_init+0x12a/0x180
[  237.382103]  [] SyS_kexec_load+0x20a/0x260
[  237.387957]  [] system_call_fastpath+0x16/0x1b

the first time allocate control pages may take too much time because
crash_res.end can be set to a higher value. we need to add cond_resched
to avoid the issue.

The patch have been tested and above issue is not appear.

Signed-off-by: zhong jiang 
---
 kernel/kexec_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 5616755..bfc9621 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -441,6 +441,8 @@ static struct page *kimage_alloc_crash_control_pages(struct 
kimage *image,
while (hole_end <= crashk_res.end) {
unsigned long i;
 
+   cond_resched();
+
if (hole_end > KEXEC_CRASH_CONTROL_MEMORY_LIMIT)
break;
/* See if I overlap any of the segments */
-- 
1.8.3.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH] kexec: add cond_resched into kimage_alloc_crash_control_pages

2016-12-07 Thread zhongjiang 
From: zhong jiang 

A soft lookup will occur when I run trinity in syscall kexec_load.
the corresponding stack information is as follows.

[  237.235937] BUG: soft lockup - CPU#6 stuck for 22s! [trinity-c6:13859]
[  237.242699] Kernel panic - not syncing: softlockup: hung tasks
[  237.248573] CPU: 6 PID: 13859 Comm: trinity-c6 Tainted: G   O L 
V---   3.10.0-327.28.3.35.zhongjiang.x86_64 #1
[  237.259984] Hardware name: Huawei Technologies Co., Ltd. Tecal BH622 
V2/BC01SRSA0, BIOS RMIBV386 06/30/2014
[  237.269752]  8187626b 18cfde31 88184c803e18 
81638f16
[  237.277471]  88184c803e98 8163278f 0008 
88184c803ea8
[  237.285190]  88184c803e48 18cfde31 88184c803e67 

[  237.292909] Call Trace:
[  237.295404][] dump_stack+0x19/0x1b
[  237.301352]  [] panic+0xd8/0x214
[  237.306196]  [] watchdog_timer_fn+0x1cc/0x1e0
[  237.312157]  [] ? watchdog_enable+0xc0/0xc0
[  237.317955]  [] __hrtimer_run_queues+0xd2/0x260
[  237.324087]  [] hrtimer_interrupt+0xb0/0x1e0
[  237.329963]  [] ? call_softirq+0x1c/0x30
[  237.335500]  [] local_apic_timer_interrupt+0x37/0x60
[  237.342228]  [] smp_apic_timer_interrupt+0x3f/0x60
[  237.348771]  [] apic_timer_interrupt+0x6d/0x80
[  237.354967][] ? 
kimage_alloc_control_pages+0x80/0x270
[  237.362875]  [] ? kmem_cache_alloc_trace+0x1ce/0x1f0
[  237.369592]  [] ? do_kimage_alloc_init+0x1f/0x90
[  237.375992]  [] kimage_alloc_init+0x12a/0x180
[  237.382103]  [] SyS_kexec_load+0x20a/0x260
[  237.387957]  [] system_call_fastpath+0x16/0x1b

the first time allocate control pages may take too much time because
crash_res.end can be set to a higher value. we need to add cond_resched
to avoid the issue.

The patch have been tested and above issue is not appear.

Signed-off-by: zhong jiang 
---
 kernel/kexec_core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 5616755..2b43cc5 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -433,6 +433,7 @@ static struct page *kimage_alloc_crash_control_pages(struct 
kimage *image,
 */
unsigned long hole_start, hole_end, size;
struct page *pages;
+   unsigned long count = 0;
 
pages = NULL;
size = (1 << order) << PAGE_SHIFT;
@@ -441,6 +442,9 @@ static struct page *kimage_alloc_crash_control_pages(struct 
kimage *image,
while (hole_end <= crashk_res.end) {
unsigned long i;
 
+   if (++count % 256 == 0)
+   cond_resched();
+
if (hole_end > KEXEC_CRASH_CONTROL_MEMORY_LIMIT)
break;
/* See if I overlap any of the segments */
-- 
1.8.3.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH v2] kexec: add resriction on the kexec_load

2016-07-21 Thread zhongjiang 
From: zhong jiang 

I hit the following question when run trinity in my system. The
kernel is 3.4 version. but the mainline have same question to be
solved. The root cause is the segment size is too large, it can
expand the most of the area or the whole memory, therefore, it
may waste an amount of time to abtain a useable page. and other
cases will block until the test case quit. at the some time,
OOM will come up.

Call Trace:
 [] __alloc_pages_nodemask+0x14c/0x8f0
 [] ? trace_hardirqs_on_thunk+0x3a/0x3c
 [] ? trace_hardirqs_on_thunk+0x3a/0x3c
 [] ? trace_hardirqs_on_thunk+0x3a/0x3c
 [] ? trace_hardirqs_on_thunk+0x3a/0x3c
 [] ? trace_hardirqs_on_thunk+0x3a/0x3c
 [] alloc_pages_current+0xaf/0x120
 [] kimage_alloc_pages+0x10/0x60
 [] kimage_alloc_control_pages+0x5d/0x270
 [] machine_kexec_prepare+0xe5/0x6c0
 [] ? kimage_free_page_list+0x52/0x70
 [] sys_kexec_load+0x141/0x600
 [] ? vfs_write+0x100/0x180
 [] system_call_fastpath+0x16/0x1b

The patch just add condition on sanity_check_segment_list to
restriction the segment size.

Signed-off-by: zhong jiang 
---
 kernel/kexec_core.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 56b3ed0..1f58824 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -148,6 +148,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
 int sanity_check_segment_list(struct kimage *image)
 {
int result, i;
+   unsigned long total_segments = 0;
unsigned long nr_segments = image->nr_segments;
 
/*
@@ -209,6 +210,21 @@ int sanity_check_segment_list(struct kimage *image)
return result;
}
 
+   /* Verity all segment size donnot exceed the specified size.
+* if segment size from user space is too large,  a large
+* amount of time will be wasted when allocating page. so,
+* softlockup may be come up.
+*/
+   for (i = 0; i < nr_segments; i++) {
+   if (image->segment[i].memsz > (totalram_pages / 2))
+   return result;
+
+   total_segments += image->segment[i].memsz;
+   }
+
+   if (total_segments > (totalram_pages / 2))
+   return result;
+
/*
 * Verify we have good destination addresses.  Normally
 * the caller is responsible for making certain we don't
-- 
1.8.3.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH v2] kexec: add resriction on the kexec_load

2016-07-21 Thread zhongjiang 
From: zhong jiang 

I hit the following question when run trinity in my system. The
kernel is 3.4 version. but the mainline have same question to be
solved. The root cause is the segment size is too large, it can
expand the most of the area or the whole memory, therefore, it
may waste an amount of time to abtain a useable page. and other
cases will block until the test case quit. at the some time,
OOM will come up.

Call Trace:
 [] __alloc_pages_nodemask+0x14c/0x8f0
 [] ? trace_hardirqs_on_thunk+0x3a/0x3c
 [] ? trace_hardirqs_on_thunk+0x3a/0x3c
 [] ? trace_hardirqs_on_thunk+0x3a/0x3c
 [] ? trace_hardirqs_on_thunk+0x3a/0x3c
 [] ? trace_hardirqs_on_thunk+0x3a/0x3c
 [] alloc_pages_current+0xaf/0x120
 [] kimage_alloc_pages+0x10/0x60
 [] kimage_alloc_control_pages+0x5d/0x270
 [] machine_kexec_prepare+0xe5/0x6c0
 [] ? kimage_free_page_list+0x52/0x70
 [] sys_kexec_load+0x141/0x600
 [] ? vfs_write+0x100/0x180
 [] system_call_fastpath+0x16/0x1b

The patch just add condition on sanity_check_segment_list to
restriction the segment size.

Signed-off-by: zhong jiang 
---
 kernel/kexec_core.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 56b3ed0..b8751c3 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -148,6 +148,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
 int sanity_check_segment_list(struct kimage *image)
 {
int result, i;
+   unsigned long total_segments = 0;
unsigned long nr_segments = image->nr_segments;
 
/*
@@ -209,6 +210,21 @@ int sanity_check_segment_list(struct kimage *image)
return result;
}
 
+   /* Verity all segment size donnot exceed the specified size.
+* if segment size from user space is too large,  a large
+* amount of time will be wasted when allocating page. so,
+* softlockup may be come up.
+*/
+   for (i = 0; i < nr_segments; i++) {
+   if (image->segment[i].memsz > (totalram_pages / 2))
+   return result;
+
+   total += image->segment[i].memsz;
+   }
+
+   if (total > (totalram_pages / 2))
+   return result;
+
/*
 * Verify we have good destination addresses.  Normally
 * the caller is responsible for making certain we don't
-- 
1.8.3.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH] kexec: add resriction on the kexec_load

2016-07-19 Thread zhongjiang 
From: zhong jiang 

I hit the following question when run trinity in my system. The
kernel is 3.4 version. but the mainline have same question to be
solved. The root cause is the segment size is too large, it can
expand the most of the area or the whole memory, therefore, it
may waste an amount of time to abtain a useable page. and other
cases will block until the test case quit. at the some time,
OOM will come up.

ck time:20160628120131-243c5
rlock reason:SOFT-WATCHDOG detected! on cpu 5.
CPU 5 Pid: 9485, comm: trinity-c5
RIP: 0010:[]  [] 
next_zones_zonelist+0x3f/0x60
RSP: 0018:88088783bc38  EFLAGS: 0283
RAX: 8808bffd9b08 RBX: 88088783bbb8 RCX: 88088783bd30
RDX: 88088f15a248 RSI: 0002 RDI: 
RBP: 88088783bc38 R08: 8808bffd8d80 R09: 000412c4d000
R10: 000412c4e000 R11:  R12: 0002
R13:  R14: 8808bffd9b00 R15: 
FS:  7f91137ee700() GS:88089f2a() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0016161a CR3: 00088782 CR4: 000407e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process trinity-c5 (pid: 9485, threadinfo 88088783a000, task 
88088f159980)
Stack:
 88088783bd88 81106eac 8808bffd8d80 
  8124c2be 0001 001e
  8124c2be 0002 8124c2be
Call Trace:
 [] __alloc_pages_nodemask+0x14c/0x8f0
 [] ? trace_hardirqs_on_thunk+0x3a/0x3c
 [] ? trace_hardirqs_on_thunk+0x3a/0x3c
 [] ? trace_hardirqs_on_thunk+0x3a/0x3c
 [] ? trace_hardirqs_on_thunk+0x3a/0x3c
 [] ? trace_hardirqs_on_thunk+0x3a/0x3c
 [] alloc_pages_current+0xaf/0x120
 [] kimage_alloc_pages+0x10/0x60
 [] kimage_alloc_control_pages+0x5d/0x270
 [] machine_kexec_prepare+0xe5/0x6c0
 [] ? kimage_free_page_list+0x52/0x70
 [] sys_kexec_load+0x141/0x600
 [] ? vfs_write+0x100/0x180
 [] system_call_fastpath+0x16/0x1b

The patch just add condition on sanity_check_segment_list to
restriction the segment size.

Signed-off-by: zhong jiang 
---
 arch/x86/include/asm/kexec.h |  1 +
 kernel/kexec_core.c  | 12 
 2 files changed, 13 insertions(+)

diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index d2434c1..b31a723 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -67,6 +67,7 @@ struct kimage;
 /* Memory to backup during crash kdump */
 #define KEXEC_BACKUP_SRC_START (0UL)
 #define KEXEC_BACKUP_SRC_END   (640 * 1024UL)  /* 640K */
+#define KEXEC_MAX_SEGMENT_SIZE (5 * 1024 * 1024UL) /* 5M */
 
 /*
  * CPU does not save ss and sp on stack if execution is already
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 448127d..35c5159 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -209,6 +209,18 @@ int sanity_check_segment_list(struct kimage *image)
return result;
}
 
+
+   /* Verity all segment size donnot exceed the specified size.
+* if segment size from user space is too large,  a large 
+* amount of time will be wasted when allocating page. so,
+* softlockup may be come up.
+*/
+   for (i = 0; i< nr_segments; i++) {
+   if (image->segment[i].memsz > KEXEC_MAX_SEGMENT_SIZE)
+   return result;
+   }
+
+
/*
 * Verify we have good destination addresses.  Normally
 * the caller is responsible for making certain we don't
-- 
1.8.3.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH] kexec: add resriction on the kexec_load

2016-07-18 Thread zhongjiang 
From: zhong jiang 

I hit the following question when run trinity in my system. The
kernel is 3.4 version. but the mainline have same question to be
solved. The root cause is the segment size is too large, it can
expand the most of the area or the whole memory, therefore, it
may waste an amount of time to abtain a useable page. and other
cases will block until the test case quit. at the some time,
OOM will come up.

ck time:20160628120131-243c5
rlock reason:SOFT-WATCHDOG detected! on cpu 5.
CPU 5 Pid: 9485, comm: trinity-c5
RIP: 0010:[]  [] 
next_zones_zonelist+0x3f/0x60
RSP: 0018:88088783bc38  EFLAGS: 0283
RAX: 8808bffd9b08 RBX: 88088783bbb8 RCX: 88088783bd30
RDX: 88088f15a248 RSI: 0002 RDI: 
RBP: 88088783bc38 R08: 8808bffd8d80 R09: 000412c4d000
R10: 000412c4e000 R11:  R12: 0002
R13:  R14: 8808bffd9b00 R15: 
FS:  7f91137ee700() GS:88089f2a() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0016161a CR3: 00088782 CR4: 000407e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process trinity-c5 (pid: 9485, threadinfo 88088783a000, task 
88088f159980)
Stack:
 88088783bd88 81106eac 8808bffd8d80 
  8124c2be 0001 001e
  8124c2be 0002 8124c2be
Call Trace:
 [] __alloc_pages_nodemask+0x14c/0x8f0
 [] ? trace_hardirqs_on_thunk+0x3a/0x3c
 [] ? trace_hardirqs_on_thunk+0x3a/0x3c
 [] ? trace_hardirqs_on_thunk+0x3a/0x3c
 [] ? trace_hardirqs_on_thunk+0x3a/0x3c
 [] ? trace_hardirqs_on_thunk+0x3a/0x3c
 [] alloc_pages_current+0xaf/0x120
 [] kimage_alloc_pages+0x10/0x60
 [] kimage_alloc_control_pages+0x5d/0x270
 [] machine_kexec_prepare+0xe5/0x6c0
 [] ? kimage_free_page_list+0x52/0x70
 [] sys_kexec_load+0x141/0x600
 [] ? vfs_write+0x100/0x180
 [] system_call_fastpath+0x16/0x1b

The patch just add condition on sanity_check_segment_list to
restriction the segment size.

Signed-off-by: zhong jiang 
---
 arch/x86/include/asm/kexec.h |  1 +
 kernel/kexec_core.c  | 12 
 2 files changed, 13 insertions(+)

diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index d2434c1..b31a723 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -67,6 +67,7 @@ struct kimage;
 /* Memory to backup during crash kdump */
 #define KEXEC_BACKUP_SRC_START (0UL)
 #define KEXEC_BACKUP_SRC_END   (640 * 1024UL)  /* 640K */
+#define KEXEC_MAX_SEGMENT_SIZE (5 * 1024 * 1024UL) /* 5M */
 
 /*
  * CPU does not save ss and sp on stack if execution is already
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 448127d..35c5159 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -209,6 +209,18 @@ int sanity_check_segment_list(struct kimage *image)
return result;
}
 
+
+   /* Verity all segment size donnot exceed the specified size.
+* if segment size from user space is too large,  a large 
+* amount of time will be wasted when allocating page. so,
+* softlockup may be come up.
+*/
+   for (i = 0; i< nr_segments; i++) {
+   if (image->segment[i].memsz > KEXEC_MAX_SEGMENT_SIZE)
+   return result;
+   }
+
+
/*
 * Verify we have good destination addresses.  Normally
 * the caller is responsible for making certain we don't
-- 
1.8.3.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 2/2] kexec: add a pmd huge entry condition during the page table

2016-07-11 Thread zhongjiang 
From: zhong jiang 

when image is loaded into kernel, we need set up page table for it. and 
all valid pfn also set up new mapping. it will tend to establish a pmd 
page table in the form of a large page if pud_present is true. relocate_kernel 
points to code segment can locate in the pmd huge entry in 
init_transtion_pgtable. 
therefore, we need to take the situation into account.

Signed-off-by: zhong jiang 
---
 arch/x86/kernel/machine_kexec_64.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/machine_kexec_64.c 
b/arch/x86/kernel/machine_kexec_64.c
index 5a294e4..c33e344 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -34,6 +35,17 @@ static struct kexec_file_ops *kexec_file_loaders[] = {
 };
 #endif
 
+static void split_pmd(pmd_t *pmd, pte_t *pte)
+{
+   unsigned long pfn = pmd_pfn(*pmd);
+   int i = 0;
+
+   do {
+   set_pte(pte, pfn_pte(pfn, PAGE_KERNEL_EXEC));
+   pfn++;
+   } while (pte++, i++, i < PTRS_PER_PTE);
+}
+
 static void free_transition_pgtable(struct kimage *image)
 {
free_page((unsigned long)image->arch.pud);
@@ -68,15 +80,19 @@ static int init_transition_pgtable(struct kimage *image, 
pgd_t *pgd)
set_pud(pud, __pud(__pa(pmd) | _KERNPG_TABLE));
}
pmd = pmd_offset(pud, vaddr);
-   if (!pmd_present(*pmd)) {
+   if (!pmd_present(*pmd) || pmd_huge(*pmd)) {
pte = (pte_t *)get_zeroed_page(GFP_KERNEL);
if (!pte)
goto err;
image->arch.pte = pte;
-   set_pmd(pmd, __pmd(__pa(pte) | _KERNPG_TABLE));
+   if (pmd_huge(*pmd))
+   split_pmd(pmd, pte);
+   else
+   set_pmd(pmd, __pmd(__pa(pte) | _KERNPG_TABLE));
}
pte = pte_offset_kernel(pmd, vaddr);
set_pte(pte, pfn_pte(paddr >> PAGE_SHIFT, PAGE_KERNEL_EXEC));
+
return 0;
 err:
free_transition_pgtable(image);
-- 
1.8.3.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 1/2] kexec: remove unnecessary unusable_pages

2016-07-11 Thread zhongjiang 
From: zhong jiang 

In general, kexec alloc pages from buddy system, it cannot exceed
the physical address in the system.

The patch just remove this unnecessary code, no functional change.

Signed-off-by: zhong jiang 
---
 include/linux/kexec.h |  1 -
 kernel/kexec_core.c   | 13 -
 2 files changed, 14 deletions(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index e8acb2b..26e4917 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -162,7 +162,6 @@ struct kimage {
 
struct list_head control_pages;
struct list_head dest_pages;
-   struct list_head unusable_pages;
 
/* Address of next control page to allocate for crash kernels. */
unsigned long control_page;
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 56b3ed0..448127d 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -257,9 +257,6 @@ struct kimage *do_kimage_alloc_init(void)
/* Initialize the list of destination pages */
INIT_LIST_HEAD(>dest_pages);
 
-   /* Initialize the list of unusable pages */
-   INIT_LIST_HEAD(>unusable_pages);
-
return image;
 }
 
@@ -517,10 +514,6 @@ static void kimage_free_extra_pages(struct kimage *image)
 {
/* Walk through and free any extra destination pages I may have */
kimage_free_page_list(>dest_pages);
-
-   /* Walk through and free any unusable pages I have cached */
-   kimage_free_page_list(>unusable_pages);
-
 }
 void kimage_terminate(struct kimage *image)
 {
@@ -647,12 +640,6 @@ static struct page *kimage_alloc_page(struct kimage *image,
page = kimage_alloc_pages(gfp_mask, 0);
if (!page)
return NULL;
-   /* If the page cannot be used file it away */
-   if (page_to_pfn(page) >
-   (KEXEC_SOURCE_MEMORY_LIMIT >> PAGE_SHIFT)) {
-   list_add(>lru, >unusable_pages);
-   continue;
-   }
addr = page_to_pfn(page) << PAGE_SHIFT;
 
/* If it is the destination page we want use it */
-- 
1.8.3.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec