Re: [PATCH v1] kexec/arch/i386: Add support for KASLR memory randomization

[Baoquan He]

On 08/17/16 at 09:47am, Thomas Garnier wrote:
> Multiple changes were made on KASLR (right now in linux-next). One of
> them is randomizing the virtual address of the physical mapping, vmalloc
> and vmemmap memory sections. It breaks kdump ability to read physical
> memory.
> 
> This change identifies if KASLR memories randomization is used by
> checking if the page_offset_base variable exists. It search for the
> correct PAGE_OFFSET value by looking at the loaded memory section and
> find the lowest aligned on PUD (the randomization level).
> 
> Related commits on linux-next:
>  - 0483e1fa6e09d4948272680f691dccb1edb9677f: Base for randomization
>  - 021182e52fe01c1f7b126f97fd6ba048dc4234fd: Enable for PAGE_OFFSET

Seems above two commits have been inside Linus's tree, while vmemmap
not yet.

> 
> Signed-off-by: Thomas Garnier 
> ---
>  kexec/arch/i386/crashdump-x86.c | 29 ++---
>  1 file changed, 22 insertions(+), 7 deletions(-)
> 
> diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
> index bbc0f35..ab833d4 100644
> --- a/kexec/arch/i386/crashdump-x86.c
> +++ b/kexec/arch/i386/crashdump-x86.c
> @@ -102,11 +102,10 @@ static int get_kernel_paddr(struct kexec_info 
> *UNUSED(info),
>   return -1;
>  }
>  
> -/* Retrieve kernel _stext symbol virtual address from /proc/kallsyms */
> -static unsigned long long get_kernel_stext_sym(void)
> +/* Retrieve kernel symbol virtual address from /proc/kallsyms */
> +static unsigned long long get_kernel_sym(const char *symbol)
>  {
>   const char *kallsyms = "/proc/kallsyms";
> - const char *stext = "_stext";
>   char sym[128];
>   char line[128];
>   FILE *fp;
> @@ -122,13 +121,13 @@ static unsigned long long get_kernel_stext_sym(void)
>   while(fgets(line, sizeof(line), fp) != NULL) {
>   if (sscanf(line, "%Lx %c %s", , , sym) != 3)
>   continue;
> - if (strcmp(sym, stext) == 0) {
> - dbgprintf("kernel symbol %s vaddr = %16llx\n", stext, 
> vaddr);
> + if (strcmp(sym, symbol) == 0) {
> + dbgprintf("kernel symbol %s vaddr = %16llx\n", symbol, 
> vaddr);
>   return vaddr;
>   }
>   }
>  
> - fprintf(stderr, "Cannot get kernel %s symbol address\n", stext);
> + fprintf(stderr, "Cannot get kernel %s symbol address\n", symbol);
>   return 0;
>  }
>  
> @@ -151,6 +150,8 @@ static int get_kernel_vaddr_and_size(struct kexec_info 
> *UNUSED(info),
>   off_t size;
>   uint32_t elf_flags = 0;
>   uint64_t stext_sym;
> + const unsigned long long pud_mask = ~((1 << 30) - 1);
> + unsigned long long vaddr, lowest_vaddr = 0;
>  
>   if (elf_info->machine != EM_X86_64)
>   return 0;
> @@ -180,9 +181,23 @@ static int get_kernel_vaddr_and_size(struct kexec_info 
> *UNUSED(info),
>  
>   end_phdr = _phdr[ehdr.e_phnum];
>  
> + /* Search for the real PAGE_OFFSET when KASLR memory randomization
> +  * is enabled */

Yeah, this is necessary. That would be great if it can be put into
get_kernel_page_offset. But then it need parse kcore elf file again,
seems no better way.

> + if (get_kernel_sym("page_offset_base") != 0) {
> + for(phdr = ehdr.e_phdr; phdr != end_phdr; phdr++) {
> + if (phdr->p_type == PT_LOAD) {
> + vaddr = phdr->p_vaddr & pud_mask;
> + if (lowest_vaddr == 0 || lowest_vaddr > vaddr)
> + lowest_vaddr = vaddr;
> + }
> + }
> + if (lowest_vaddr != 0)
> + elf_info->page_offset = lowest_vaddr;
> + }
> +
>   /* Traverse through the Elf headers and find the region where
>* _stext symbol is located in. That's where kernel is mapped */
> - stext_sym = get_kernel_stext_sym();
> + stext_sym = get_kernel_sym("_stext");
>   for(phdr = ehdr.e_phdr; stext_sym && phdr != end_phdr; phdr++) {
>   if (phdr->p_type == PT_LOAD) {
>   unsigned long long saddr = phdr->p_vaddr;
> -- 
> 2.8.0.rc3.226.g39d4020
> 
> 
> ___
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

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

[PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

[Zhou Wenjian]

nr_cpus can help to save memory. So we should remind user of it.

Signed-off-by: Zhou Wenjian 
Acked-by: Baoquan He 
Acked-by: Xunlei Pang 
---
 Documentation/kdump/kdump.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 88ff63d..d900080 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -393,6 +393,8 @@ Notes on loading the dump-capture kernel:
 * We generally don' have to bring up a SMP kernel just to capture the
   dump. Hence generally it is useful either to build a UP dump-capture
   kernel or specify maxcpus=1 option while loading dump-capture kernel.
+  Note, though maxcpus always works, you should replace it by nr_cpus to
+  save memory if supported by the current ARCH, such as x86.
 
 * For s390x there are two kdump modes: If a ELF header is specified with
   the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
-- 
1.8.3.1




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

[PATCH v9 0/2] update the doc of kdump

[Zhou Wenjian]

v8->v9: rearrange the patch.
it won't fix typo which original exists.
those should be fixed in other patch, which I'll post later.
v7->v8: fix "a SMP kernel" to "an SMP kernel" and replace "\" with "/"
v6->v7: fix typo
v5->v6: replace "we" with "you"
v4->v5: move change log to cover letter
v3->v4: update the description of bring up SMP dump-capture kernel
v2->v3: add description of nr_cpus.
v1->v2: change nr_cpus to maxcpus

Zhou Wenjian (2):
  Documentation: kdump: remind user of nr_cpus
  Documentation: kdump: add description of enable multi-cpus support

 Documentation/kdump/kdump.txt | 9 +
 1 file changed, 9 insertions(+)

-- 
1.8.3.1




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

[PATCH v9 2/2] Documentation: kdump: add description of enable multi-cpus support

[Zhou Wenjian]

multi-cpu support is useful to improve the performance of kdump in
some cases. So add the description of enable multi-cpu support in
dump-capture kernel.

Signed-off-by: Zhou Wenjian 
Acked-by: Baoquan He 
Acked-by: Xunlei Pang 
---
 Documentation/kdump/kdump.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index d900080..31e6b88 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -396,6 +396,13 @@ Notes on loading the dump-capture kernel:
   Note, though maxcpus always works, you should replace it by nr_cpus to
   save memory if supported by the current ARCH, such as x86.
 
+* You should enable multi-cpu support in dump-capture kernel if you intend
+  to use multi-thread programs with it, such as parallel dump feature of
+  makedumpfile. Otherwise, the multi-thread program may have a great
+  performance degradation. To enable multi-cpu support, you should bring up an
+  SMP dump-capture kernel and specify maxcpus/nr_cpus, disable_cpu_apicid=[X]
+  options while loading it.
+
 * For s390x there are two kdump modes: If a ELF header is specified with
   the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
   is done on all other architectures. If no elfcorehdr= kernel parameter is
-- 
1.8.3.1




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

Re: [PATCH v8 1/2] Documentation: kdump: remind user of nr_cpus

[Joe Perches]

On Thu, 2016-08-18 at 10:31 +0800, Zhou Wenjian wrote:
> nr_cpus can help to save memory. So we should remind user of it.

trivia:
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
[]
> @@ -390,9 +390,11 @@ Notes on loading the dump-capture kernel:
>  * Boot parameter "1" boots the dump-capture kernel into single-user
>    mode without networking. If you want networking, use "3".
>  
> -* We generally don' have to bring up a SMP kernel just to capture the
> +* We generally don' have to bring up an SMP kernel just to capture the

don't or do not


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

[PATCH v8 2/2] Documentation: kdump: add description of enable multi-cpus support

[Zhou Wenjian]

multi-cpu support is useful to improve the performance of kdump in
some cases. So add the description of enable multi-cpu support in
dump-capture kernel.

Signed-off-by: Zhou Wenjian 
Acked-by: Baoquan He 
Acked-by: Xunlei Pang 
---
 Documentation/kdump/kdump.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index e8da1d5..c781d49 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -396,6 +396,13 @@ Notes on loading the dump-capture kernel:
   Note, though maxcpus always works, you should replace it by nr_cpus to
   save memory if supported by the current ARCH, such as x86.
 
+* You should enable multi-cpu support in dump-capture kernel if you intend
+  to use multi-thread programs with it, such as parallel dump feature of
+  makedumpfile. Otherwise, the multi-thread program may have a great
+  performance degradation. To enable multi-cpu support, you should bring up an
+  SMP dump-capture kernel and specify maxcpus/nr_cpus, disable_cpu_apicid=[X]
+  options while loading it.
+
 * For s390x there are two kdump modes: If a ELF header is specified with
   the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
   is done on all other architectures. If no elfcorehdr= kernel parameter is
-- 
1.8.3.1




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

[PATCH v8 1/2] Documentation: kdump: remind user of nr_cpus

[Zhou Wenjian]

nr_cpus can help to save memory. So we should remind user of it.

Signed-off-by: Zhou Wenjian 
Acked-by: Baoquan He 
Acked-by: Xunlei Pang 
---
 Documentation/kdump/kdump.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 88ff63d..e8da1d5 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -390,9 +390,11 @@ Notes on loading the dump-capture kernel:
 * Boot parameter "1" boots the dump-capture kernel into single-user
   mode without networking. If you want networking, use "3".
 
-* We generally don' have to bring up a SMP kernel just to capture the
+* We generally don' have to bring up an SMP kernel just to capture the
   dump. Hence generally it is useful either to build a UP dump-capture
   kernel or specify maxcpus=1 option while loading dump-capture kernel.
+  Note, though maxcpus always works, you should replace it by nr_cpus to
+  save memory if supported by the current ARCH, such as x86.
 
 * For s390x there are two kdump modes: If a ELF header is specified with
   the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
-- 
1.8.3.1




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

[PATCH v8 0/2] update the doc of kdump

[Zhou Wenjian]

v7->v8: fix "a SMP kernel" to "an SMP kernel" and replace "\" with "/"
v6->v7: fix typo
v5->v6: replace "we" with "you"
v4->v5: move change log to cover letter
v3->v4: update the description of bring up SMP dump-capture kernel
v2->v3: add description of nr_cpus.
v1->v2: change nr_cpus to maxcpus

Zhou Wenjian (2):
  Documentation: kdump: remind user of nr_cpus
  Documentation: kdump: add description of enable multi-cpus support

 Documentation/kdump/kdump.txt | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

-- 
1.8.3.1




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

Re: [PATCH v7 2/2] Documentation: kdump: add description of enable multi-cpus support

[Xunlei Pang]

On 2016/08/18 at 09:50, Zhou Wenjian wrote:
> multi-cpu support is useful to improve the performance of kdump in
> some cases. So add the description of enable multi-cpu support in
> dump-capture kernel.
>
> Signed-off-by: Zhou Wenjian 
> Acked-by: Baoquan He 
> ---
>  Documentation/kdump/kdump.txt | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> index 96da2b7..c93a6e0 100644
> --- a/Documentation/kdump/kdump.txt
> +++ b/Documentation/kdump/kdump.txt
> @@ -396,6 +396,13 @@ Notes on loading the dump-capture kernel:
>Note, though maxcpus always works, you should replace it by nr_cpus to
>save memory if supported by the current ARCH, such as x86.
>  
> +* You should enable multi-cpu support in dump-capture kernel if you intend
> +  to use multi-thread programs with it, such as parallel dump feature of
> +  makedumpfile. Otherwise, the multi-thread program may have a great
> +  performance degradation. To enable multi-cpu support, you should bring up
> +  a SMP dump-capture kernel and specify maxcpus\nr_cpus, 
> disable_cpu_apicid=[X]

s/a SMP/an SMP/
For "maxcpus\nr_cpus", I think to use slash instead of backslash in Linux is 
better.

Otherwise, looks good to me.

Regards,
Xunlei

> +  options while loading it.
> +
>  * For s390x there are two kdump modes: If a ELF header is specified with
>the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
>is done on all other architectures. If no elfcorehdr= kernel parameter is


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

[PATCH v7 1/2] Documentation: kdump: remind user of nr_cpus

[Zhou Wenjian]

nr_cpus can help to save memory. So we should remind user of it.

Signed-off-by: Zhou Wenjian 
Acked-by: Baoquan He 
---
 Documentation/kdump/kdump.txt | 2 +++-
 1 file changed, 2 insertions(+)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 88ff63d..96da2b7 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -393,6 +393,8 @@ Notes on loading the dump-capture kernel:
 * We generally don' have to bring up a SMP kernel just to capture the
   dump. Hence generally it is useful either to build a UP dump-capture
   kernel or specify maxcpus=1 option while loading dump-capture kernel.
+  Note, though maxcpus always works, you should replace it by nr_cpus to
+  save memory if supported by the current ARCH, such as x86.
 
 * For s390x there are two kdump modes: If a ELF header is specified with
   the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
-- 
1.8.3.1




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

[PATCH v7 0/2] update the doc of kdump

[Zhou Wenjian]

v6->v7: fix typo
v5->v6: replace "we" with "you"
v4->v5: move change log to cover letter
v3->v4: update the description of bring up SMP dump-capture kernel
v2->v3: add description of nr_cpus.
v1->v2: change nr_cpus to maxcpus


Zhou Wenjian (2):
  Documentation: kdump: remind user of nr_cpus
  Documentation: kdump: add description of enable multi-cpus support

 Documentation/kdump/kdump.txt | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

-- 
1.8.3.1




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

[PATCH v7 2/2] Documentation: kdump: add description of enable multi-cpus support

[Zhou Wenjian]

multi-cpu support is useful to improve the performance of kdump in
some cases. So add the description of enable multi-cpu support in
dump-capture kernel.

Signed-off-by: Zhou Wenjian 
Acked-by: Baoquan He 
---
 Documentation/kdump/kdump.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 96da2b7..c93a6e0 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -396,6 +396,13 @@ Notes on loading the dump-capture kernel:
   Note, though maxcpus always works, you should replace it by nr_cpus to
   save memory if supported by the current ARCH, such as x86.
 
+* You should enable multi-cpu support in dump-capture kernel if you intend
+  to use multi-thread programs with it, such as parallel dump feature of
+  makedumpfile. Otherwise, the multi-thread program may have a great
+  performance degradation. To enable multi-cpu support, you should bring up
+  a SMP dump-capture kernel and specify maxcpus\nr_cpus, disable_cpu_apicid=[X]
+  options while loading it.
+
 * For s390x there are two kdump modes: If a ELF header is specified with
   the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
   is done on all other architectures. If no elfcorehdr= kernel parameter is
-- 
1.8.3.1




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

[PATCH v1] kexec/arch/i386: Add support for KASLR memory randomization

[Thomas Garnier]

Multiple changes were made on KASLR (right now in linux-next). One of
them is randomizing the virtual address of the physical mapping, vmalloc
and vmemmap memory sections. It breaks kdump ability to read physical
memory.

This change identifies if KASLR memories randomization is used by
checking if the page_offset_base variable exists. It search for the
correct PAGE_OFFSET value by looking at the loaded memory section and
find the lowest aligned on PUD (the randomization level).

Related commits on linux-next:
 - 0483e1fa6e09d4948272680f691dccb1edb9677f: Base for randomization
 - 021182e52fe01c1f7b126f97fd6ba048dc4234fd: Enable for PAGE_OFFSET

Signed-off-by: Thomas Garnier 
---
 kexec/arch/i386/crashdump-x86.c | 29 ++---
 1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index bbc0f35..ab833d4 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -102,11 +102,10 @@ static int get_kernel_paddr(struct kexec_info 
*UNUSED(info),
return -1;
 }
 
-/* Retrieve kernel _stext symbol virtual address from /proc/kallsyms */
-static unsigned long long get_kernel_stext_sym(void)
+/* Retrieve kernel symbol virtual address from /proc/kallsyms */
+static unsigned long long get_kernel_sym(const char *symbol)
 {
const char *kallsyms = "/proc/kallsyms";
-   const char *stext = "_stext";
char sym[128];
char line[128];
FILE *fp;
@@ -122,13 +121,13 @@ static unsigned long long get_kernel_stext_sym(void)
while(fgets(line, sizeof(line), fp) != NULL) {
if (sscanf(line, "%Lx %c %s", , , sym) != 3)
continue;
-   if (strcmp(sym, stext) == 0) {
-   dbgprintf("kernel symbol %s vaddr = %16llx\n", stext, 
vaddr);
+   if (strcmp(sym, symbol) == 0) {
+   dbgprintf("kernel symbol %s vaddr = %16llx\n", symbol, 
vaddr);
return vaddr;
}
}
 
-   fprintf(stderr, "Cannot get kernel %s symbol address\n", stext);
+   fprintf(stderr, "Cannot get kernel %s symbol address\n", symbol);
return 0;
 }
 
@@ -151,6 +150,8 @@ static int get_kernel_vaddr_and_size(struct kexec_info 
*UNUSED(info),
off_t size;
uint32_t elf_flags = 0;
uint64_t stext_sym;
+   const unsigned long long pud_mask = ~((1 << 30) - 1);
+   unsigned long long vaddr, lowest_vaddr = 0;
 
if (elf_info->machine != EM_X86_64)
return 0;
@@ -180,9 +181,23 @@ static int get_kernel_vaddr_and_size(struct kexec_info 
*UNUSED(info),
 
end_phdr = _phdr[ehdr.e_phnum];
 
+   /* Search for the real PAGE_OFFSET when KASLR memory randomization
+* is enabled */
+   if (get_kernel_sym("page_offset_base") != 0) {
+   for(phdr = ehdr.e_phdr; phdr != end_phdr; phdr++) {
+   if (phdr->p_type == PT_LOAD) {
+   vaddr = phdr->p_vaddr & pud_mask;
+   if (lowest_vaddr == 0 || lowest_vaddr > vaddr)
+   lowest_vaddr = vaddr;
+   }
+   }
+   if (lowest_vaddr != 0)
+   elf_info->page_offset = lowest_vaddr;
+   }
+
/* Traverse through the Elf headers and find the region where
 * _stext symbol is located in. That's where kernel is mapped */
-   stext_sym = get_kernel_stext_sym();
+   stext_sym = get_kernel_sym("_stext");
for(phdr = ehdr.e_phdr; stext_sym && phdr != end_phdr; phdr++) {
if (phdr->p_type == PT_LOAD) {
unsigned long long saddr = phdr->p_vaddr;
-- 
2.8.0.rc3.226.g39d4020


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

[PATCH] fixup! arm64: kdump: add kdump support

[James Morse]

copy_oldmem_page() and mmap_vmcore() provide two ways for userspace to read
from /proc/vmcore. Neither of these check with memblock to see if the page
they are accessing is nomap. On Seattle this causes:

[  174.393875] Unhandled fault: synchronous external abort (0x96000210) at
0xff80096b6000
[  174.402158] Internal error: : 96000210 [#1] PREEMPT SMP
[  174.407370] Modules linked in:
[  174.410417] CPU: 6 PID: 2059 Comm: cp Tainted: G S  W I 4.8.0-rc1+ 
#4708
[  174.417799] Hardware name: AMD Overdrive/Supercharger/Default string, BIOS
ROD1002C 04/08/2016
[  174.426396] task: ffc0fdec5780 task.stack: ffc0f34bc000
[  174.432313] PC is at __arch_copy_to_user+0x180/0x280
[  174.437274] LR is at copy_oldmem_page+0xac/0xf0
[  174.441791] pc : [] lr : [] pstate: 
2145
[  174.449173] sp : ffc0f34bfc90
[  174.452474] x29: ffc0f34bfc90 x28: 
[  174.457776] x27: 0800 x26: d000
[  174.463077] x25: 0001 x24: ff8008eb5000
[  174.468378] x23:  x22: ff80096b6000
[  174.473679] x21: 0001 x20: 30127000
[  174.478979] x19: 1000 x18: 007ff7085d60
[  174.484279] x17: 00429358 x16: ff80081d9e88
[  174.489579] x15: 007fae377590 x14: 

[  174.494880] x13:  x12: ff8008dd1000
[  174.500180] x11: ff80096b6fff x10: ff80096b6fff
[  174.505480] x9 : 4000 x8 : ff8008db6000
[  174.510781] x7 : ff80096b7000 x6 : 30127000
[  174.516082] x5 : 30128000 x4 : 
[  174.521382] x3 : 00e80713 x2 : 0f80
[  174.526682] x1 : ff80096b6000 x0 : 30127000
[  174.531982]
[  174.533461] Process cp (pid: 2059, stack limit = 0xffc0f34bc020)

[  174.848448] [] __arch_copy_to_user+0x180/0x280
[  174.854448] [] read_from_oldmem.part.4+0xb4/0xf4
[  174.860615] [] read_vmcore+0x100/0x22c
[  174.865919] [] proc_reg_read+0x64/0x90
[  174.871223] [] __vfs_read+0x28/0x108
[  174.876348] [] vfs_read+0x84/0x144
[  174.881301] [] SyS_read+0x44/0xa0
[  174.886167] [] el0_svc_naked+0x24/0x28
[  174.891466] Code:     (a8c12027)
[  174.897562] ---[ end trace 00801b2e35b0cd1f ]---

When reading /proc/vmcore with cat/cp or or mmap()ing it with makedumpfile.

The fs/proc/vmcore.c code provides a hook to indicate whether oldmem pages
are ram or not. Use this to look for our earlier handiwork in memblock.

Signed-off-by: James Morse 
---

Hi Pratyush,

I couldn't get makedumpfile to build, or rather it depends on elfutils which
wouldn't build for autotools reasons. Does implementing this hook solve your
makedumpfile issue?

With this patch I can extract a usable vmcore file using read or mmap,
avoiding the earlier splat.

Akashi, if you agree this is the right thing to do, please consider folding
this into patch 5. (no need to keep the commit mesage or anything).

Thanks,

James

 arch/arm64/kernel/crash_dump.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm64/kernel/crash_dump.c b/arch/arm64/kernel/crash_dump.c
index 2dc54d129be1..76c71ab42994 100644
--- a/arch/arm64/kernel/crash_dump.c
+++ b/arch/arm64/kernel/crash_dump.c
@@ -12,10 +12,38 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
+#ifdef CONFIG_PROC_VMCORE
+static int oldmem_pfn_is_ram(unsigned long pfn)
+{
+   unsigned long addr = pfn << PAGE_SHIFT;
+
+   /*
+* We removed oldmem from memblock.memory, then re-added some regions
+* which are reserved by/for firmware as memory and nomap.
+* If an address exists as memory, but is marked nomap, return false.
+*/
+   if (memblock_is_memory(addr) && !memblock_is_map_memory(addr))
+   return 0;
+
+   return 1;
+}
+
+static int __init do_register_oldmem_pfn_is_ram(void)
+{
+   return register_oldmem_pfn_is_ram(_pfn_is_ram);
+}
+/*
+ * vmcore_init() is called via fs_initcall, ensure we register
+ * oldmem_pfn_is_ram() before then.
+ */
+arch_initcall(do_register_oldmem_pfn_is_ram);
+#endif
+
 /**
  * copy_oldmem_page() - copy one page from old kernel memory
  * @pfn: page frame number to be copied
-- 
2.8.0.rc3


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

Re: [PATCH v2 1/2] kexec: Introduce "/sys/kernel/kexec_crash_low_size"

[Dave Young]

On 08/17/16 at 09:50am, Xunlei Pang wrote:
> "/sys/kernel/kexec_crash_size" only handles crashk_res, it
> is fine in most cases, but sometimes we have crashk_low_res.
> For example, when "crashkernel=size[KMG],high" combined with
> "crashkernel=size[KMG],low" is used for 64-bit x86.
> 
> Like crashk_res, we introduce the corresponding sysfs file
> "/sys/kernel/kexec_crash_low_size" for crashk_low_res.
> 
> So, the exact total reserved memory is the sum of the two.
> 
> crashk_low_res can also be shrunk via this new interface,
> and users should be aware of what they are doing.

Cc Yinghai Lu for review since he introduced the ,high and ,low logic.

> 
> Suggested-by: Dave Young 
> Signed-off-by: Xunlei Pang 
> ---
>  include/linux/kexec.h |  4 ++--
>  kernel/kexec_core.c   | 23 ---
>  kernel/ksysfs.c   | 25 +++--
>  3 files changed, 37 insertions(+), 15 deletions(-)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index d743777..4f271fc 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -304,8 +304,8 @@ int parse_crashkernel_high(char *cmdline, unsigned long 
> long system_ram,
>   unsigned long long *crash_size, unsigned long long *crash_base);
>  int parse_crashkernel_low(char *cmdline, unsigned long long system_ram,
>   unsigned long long *crash_size, unsigned long long *crash_base);
> -int crash_shrink_memory(unsigned long new_size);
> -size_t crash_get_memory_size(void);
> +int crash_shrink_memory(struct resource *res, unsigned long new_size);
> +size_t crash_get_memory_size(struct resource *res);
>  void crash_free_reserved_phys_range(unsigned long begin, unsigned long end);
>  
>  int __weak arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 5616755..707d18e 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -925,13 +925,13 @@ void crash_kexec(struct pt_regs *regs)
>   }
>  }
>  
> -size_t crash_get_memory_size(void)
> +size_t crash_get_memory_size(struct resource *res)
>  {
>   size_t size = 0;
>  
>   mutex_lock(_mutex);
> - if (crashk_res.end != crashk_res.start)
> - size = resource_size(_res);
> + if (res->end != res->start)
> + size = resource_size(res);
>   mutex_unlock(_mutex);
>   return size;
>  }
> @@ -945,7 +945,7 @@ void __weak crash_free_reserved_phys_range(unsigned long 
> begin,
>   free_reserved_page(boot_pfn_to_page(addr >> PAGE_SHIFT));
>  }
>  
> -int crash_shrink_memory(unsigned long new_size)
> +int crash_shrink_memory(struct resource *res, unsigned long new_size)
>  {
>   int ret = 0;
>   unsigned long start, end;
> @@ -958,8 +958,9 @@ int crash_shrink_memory(unsigned long new_size)
>   ret = -ENOENT;
>   goto unlock;
>   }
> - start = crashk_res.start;
> - end = crashk_res.end;
> +
> + start = res->start;
> + end = res->end;
>   old_size = (end == 0) ? 0 : end - start + 1;
>   if (new_size >= old_size) {
>   ret = (new_size == old_size) ? 0 : -EINVAL;
> @@ -975,17 +976,17 @@ int crash_shrink_memory(unsigned long new_size)
>   start = roundup(start, KEXEC_CRASH_MEM_ALIGN);
>   end = roundup(start + new_size, KEXEC_CRASH_MEM_ALIGN);
>  
> - crash_free_reserved_phys_range(end, crashk_res.end);
> + crash_free_reserved_phys_range(end, res->end);
>  
> - if ((start == end) && (crashk_res.parent != NULL))
> - release_resource(_res);
> + if ((start == end) && (res->parent != NULL))
> + release_resource(res);
>  
>   ram_res->start = end;
> - ram_res->end = crashk_res.end;
> + ram_res->end = res->end;
>   ram_res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
>   ram_res->name = "System RAM";
>  
> - crashk_res.end = end - 1;
> + res->end = end - 1;
>  
>   insert_resource(_resource, ram_res);
>  
> diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
> index ee1bc1b..3336fd5 100644
> --- a/kernel/ksysfs.c
> +++ b/kernel/ksysfs.c
> @@ -105,10 +105,30 @@ static ssize_t kexec_crash_loaded_show(struct kobject 
> *kobj,
>  }
>  KERNEL_ATTR_RO(kexec_crash_loaded);
>  
> +static ssize_t kexec_crash_low_size_show(struct kobject *kobj,
> +struct kobj_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%zu\n", crash_get_memory_size(_low_res));
> +}
> +static ssize_t kexec_crash_low_size_store(struct kobject *kobj,
> +struct kobj_attribute *attr,
> +const char *buf, size_t count)
> +{
> + unsigned long cnt;
> + int ret;
> +
> + if (kstrtoul(buf, 0, ))
> + return -EINVAL;
> +
> + ret = crash_shrink_memory(_low_res, cnt);
> + return ret < 0 ? ret : count;
> +}
> +KERNEL_ATTR_RW(kexec_crash_low_size);
> +
>  static 

Re: [PATCH v2 2/2] kexec: Consider crashk_low_res in sanity_check_segment_list()

[Xunlei Pang]

On 2016/08/17 at 15:24, Dave Young wrote:
> Hi, Xunlei,
>
> On 08/17/16 at 09:50am, Xunlei Pang wrote:
>> We have crashk_res only in most cases, but sometimes we have
>> crashk_low_res.
>>
>> For example, on 64-bit x86 systems, when "crashkernel=32M,high"
>> combined with "crashkernel=128M,low" is used, so some segments
>> may have the chance to be loaded into crashk_low_res area. We
>> can't fail it as a memory violation in these cases.
>>
>> Thus, we add the case to regard the segment as valid if it is
>> within crashk_low_res.
> crashkernel low is meant for swiotlb, it can be reserved automaticlly
> in case there's only crashkernel high specified in cmdline, I'm not
> sure it is useful to use crashk_res_low for other purpose and
> likely kdump can fail in the case. 
>
> I'm not sure it is really necessary to add this check now, we may
> handle it only when there is an actual use case and bug report in
> the future.

Thanks for the review.
The reason I added this is that crashk_res is allowed to be shrunk, so the 
segment
will surely fall into crashk_low_res if crashk_res was shrunk to be a small 
range.

But yes, this should be a corner case, but seems it does no harm adding this 
check.
Anyway, if you think it's not necessary, let's simply ignore it :-)

Regards,
Xunlei

>
> Thanks
> Dave
>> Signed-off-by: Xunlei Pang 
>> ---
>>  kernel/kexec_core.c | 11 ---
>>  1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
>> index 707d18e..9012a60 100644
>> --- a/kernel/kexec_core.c
>> +++ b/kernel/kexec_core.c
>> @@ -248,9 +248,14 @@ int sanity_check_segment_list(struct kimage *image)
>>  mstart = image->segment[i].mem;
>>  mend = mstart + image->segment[i].memsz - 1;
>>  /* Ensure we are within the crash kernel limits */
>> -if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
>> -(mend > phys_to_boot_phys(crashk_res.end)))
>> -return -EADDRNOTAVAIL;
>> +if ((mstart >= phys_to_boot_phys(crashk_res.start)) &&
>> +(mend <= phys_to_boot_phys(crashk_res.end)))
>> +continue;
>> +if ((mstart >= phys_to_boot_phys(crashk_low_res.start)) 
>> &&
>> +(mend <= phys_to_boot_phys(crashk_low_res.end)))
>> +continue;
>> +
>> +return -EADDRNOTAVAIL;
>>  }
>>  }
>>  
>> -- 
>> 1.8.3.1
>>
> ___
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec


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

Re: [PATCH 3/3] close_dump_bitmap: simplify logic

[Martin Wilck]

On Tue, 2016-08-16 at 07:59 +0200, Petr Tesarik wrote:
> On Tue, 16 Aug 2016 00:37:09 +
> Atsushi Kumagai  wrote:
> 
> > So, could you work for that cleanup before your three patches as an
> > additional cleanup patch ?
> 
> OK, I take it. ;-)
> 
> Martin, do you mind rebasing your patch when I'm done with the
> cleanup?

No problem.

Regards
Martin



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

Re: [PATCH v2 2/2] kexec: Consider crashk_low_res in sanity_check_segment_list()

[Dave Young]

Hi, Xunlei,

On 08/17/16 at 09:50am, Xunlei Pang wrote:
> We have crashk_res only in most cases, but sometimes we have
> crashk_low_res.
> 
> For example, on 64-bit x86 systems, when "crashkernel=32M,high"
> combined with "crashkernel=128M,low" is used, so some segments
> may have the chance to be loaded into crashk_low_res area. We
> can't fail it as a memory violation in these cases.
> 
> Thus, we add the case to regard the segment as valid if it is
> within crashk_low_res.

crashkernel low is meant for swiotlb, it can be reserved automaticlly
in case there's only crashkernel high specified in cmdline, I'm not
sure it is useful to use crashk_res_low for other purpose and
likely kdump can fail in the case. 

I'm not sure it is really necessary to add this check now, we may
handle it only when there is an actual use case and bug report in
the future.

Thanks
Dave
> 
> Signed-off-by: Xunlei Pang 
> ---
>  kernel/kexec_core.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 707d18e..9012a60 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -248,9 +248,14 @@ int sanity_check_segment_list(struct kimage *image)
>   mstart = image->segment[i].mem;
>   mend = mstart + image->segment[i].memsz - 1;
>   /* Ensure we are within the crash kernel limits */
> - if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
> - (mend > phys_to_boot_phys(crashk_res.end)))
> - return -EADDRNOTAVAIL;
> + if ((mstart >= phys_to_boot_phys(crashk_res.start)) &&
> + (mend <= phys_to_boot_phys(crashk_res.end)))
> + continue;
> + if ((mstart >= phys_to_boot_phys(crashk_low_res.start)) 
> &&
> + (mend <= phys_to_boot_phys(crashk_low_res.end)))
> + continue;
> +
> + return -EADDRNOTAVAIL;
>   }
>   }
>  
> -- 
> 1.8.3.1
> 

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

Re: [PATCH v2 4/6] kexec_file: Add mechanism to update kexec segments.

[Thiago Jung Bauermann]

Hello Andrew,

Thank you for your review!

Am Montag, 15 August 2016, 15:27:56 schrieb Andrew Morton:
> On Sat, 13 Aug 2016 00:18:23 -0300 Thiago Jung Bauermann 
>  wrote:
> > +/**
> > + * kexec_update_segment - update the contents of a kimage segment
> > + * @buffer:New contents of the segment.
> > + * @bufsz: @buffer size.
> > + * @load_addr: Segment's physical address in the next kernel.
> > + * @memsz: Segment size.
> > + *
> > + * This function assumes kexec_mutex is held.
> > + *
> > + * Return: 0 on success, negative errno on error.
> > + */
> > +int kexec_update_segment(const char *buffer, unsigned long bufsz,
> > +unsigned long load_addr, unsigned long memsz)
> > +{
> > +   int i;
> > +   unsigned long entry;
> > +   unsigned long *ptr = NULL;
> > +   void *dest = NULL;
> > +
> > +   if (kexec_image == NULL) {
> > +   pr_err("Can't update segment: no kexec image loaded.\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   /*
> > +* kexec_add_buffer rounds up segment sizes to PAGE_SIZE, so
> > +* we have to do it here as well.
> > +*/
> > +   memsz = ALIGN(memsz, PAGE_SIZE);
> > +
> > +   for (i = 0; i < kexec_image->nr_segments; i++)
> > +   /* We only support updating whole segments. */
> > +   if (load_addr == kexec_image->segment[i].mem &&
> > +   memsz == kexec_image->segment[i].memsz) {
> > +   if (kexec_image->segment[i].do_checksum) {
> > +   pr_err("Trying to update non-modifiable 
> > segment.\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   break;
> > +   }
> > +   if (i == kexec_image->nr_segments) {
> > +   pr_err("Couldn't find segment to update: 0x%lx, size 0x%lx\n",
> > +  load_addr, memsz);
> > +   return -EINVAL;
> > +   }
> > +
> > +   for (entry = kexec_image->head; !(entry & IND_DONE) && memsz;
> > +entry = *ptr++) {
> > +   void *addr = (void *) (entry & PAGE_MASK);
> > +
> > +   switch (entry & IND_FLAGS) {
> > +   case IND_DESTINATION:
> > +   dest = addr;
> > +   break;
> > +   case IND_INDIRECTION:
> > +   ptr = __va(addr);
> > +   break;
> > +   case IND_SOURCE:
> > +   /* Shouldn't happen, but verify just to be safe. */
> > +   if (dest == NULL) {
> > +   pr_err("Invalid kexec entries list.");
> > +   return -EINVAL;
> > +   }
> > +
> > +   if (dest == (void *) load_addr) {
> > +   struct page *page;
> > +   char *ptr;
> > +   size_t uchunk, mchunk;
> > +
> > +   page = kmap_to_page(addr);
> > +
> > +   ptr = kmap(page);
> 
> kmap_atomic() could be used here, and it is appreciably faster.

Good idea. The patch below implements your suggestion.

This has a consequence for patch 5/6 in this series, because it makes
this code be used in the path of the kexec_file_load and
kexec_load syscalls.

In the latter case, there's a call to copy_from_user and thus kmap_atomic 
can't be used. I can change the patch to use kmap_atomic if
state->from_kernel is true and kmap otherwise, but perhaps this is one more 
hint that patch 5/6 is not a very good idea after all.

-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center


Subject: [PATCH v2 4/6] kexec_file: Add mechanism to update kexec segments.

kexec_update_segment allows a given segment in kexec_image to have
its contents updated. This is useful if the current kernel wants to
send information to the next kernel that is up-to-date at the time of
reboot.

Signed-off-by: Thiago Jung Bauermann 
---
 include/linux/kexec.h |  2 ++
 kernel/kexec_core.c   | 99 +++
 2 files changed, 101 insertions(+)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 37eea32fdff1..14dda81e3e01 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -259,6 +259,8 @@ extern int kexec_purgatory_get_set_symbol(struct kimage 
*image,
  unsigned int size, bool get_value);
 extern void *kexec_purgatory_get_symbol_addr(struct kimage *image,
 const char *name);
+int kexec_update_segment(const char *buffer, unsigned long bufsz,
+unsigned long load_addr, unsigned long memsz);
 extern void __crash_kexec(struct pt_regs *);
 extern void crash_kexec(struct pt_regs *);
 int kexec_should_crash(struct task_struct *);
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 561675589511..9782b292714e 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -721,6 

Re: [PATCH v2 0/6] kexec_file: Add buffer hand-over for the next kernel

[Dave Young]

On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote:
> Hello,
> 
> This patch series implements a mechanism which allows the kernel to pass
> on a buffer to the kernel that will be kexec'd. This buffer is passed
> as a segment which is added to the kimage when it is being prepared
> by kexec_file_load.
> 
> How the second kernel is informed of this buffer is architecture-specific.
> On powerpc, this is done via the device tree, by checking
> the properties /chosen/linux,kexec-handover-buffer-start and
> /chosen/linux,kexec-handover-buffer-end, which is analogous to how the
> kernel finds the initrd.
> 
> This is needed because the Integrity Measurement Architecture subsystem
> needs to preserve its measurement list accross the kexec reboot. The
> following patch series for the IMA subsystem uses this feature for that
> purpose:
> 
> https://lists.infradead.org/pipermail/kexec/2016-August/016745.html
> 
> This is so that IMA can implement trusted boot support on the OpenPower
> platform, because on such systems an intermediary Linux instance running
> as part of the firmware is used to boot the target operating system via
> kexec. Using this mechanism, IMA on this intermediary instance can
> hand over to the target OS the measurements of the components that were
> used to boot it.
> 
> Because there could be additional measurement events between the
> kexec_file_load call and the actual reboot, IMA needs a way to update the
> buffer with those additional events before rebooting. One can minimize
> the interval between the kexec_file_load and the reboot syscalls, but as
> small as it can be, there is always the possibility that the measurement
> list will be out of date at the time of reboot.
> 
> To address this issue, this patch series also introduces
> kexec_update_segment, which allows a reboot notifier to change the
> contents of the image segment during the reboot process.
> 
> Patch 5 makes kimage_load_normal_segment and kexec_update_segment share
> code. It's not much code that they can share though, so I'm not sure if
> the result is actually better.
> 
> The last patch is not intended to be merged, it just demonstrates how
> this feature can be used.
> 
> This series applies on top of v5 of the "kexec_file_load implementation
> for PowerPC" patch series (which applies on top of v4.8-rc1):
> 
> https://lists.infradead.org/pipermail/kexec/2016-August/016843.html

I'm trying to review your patches, but seems I can not apply them
cleanly to mainline kernel or v4.8-rc1

Apply the kexec_file_load series failed as below on v4.8-rc1:

Applying: kexec_file: Allow arch-specific memory walking for
kexec_add_buffer
error: patch failed: include/linux/kexec.h:149
error: include/linux/kexec.h: patch does not apply
Patch failed at 0001 kexec_file: Allow arch-specific memory walking for
kexec_add_buffer
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

What is the order of your patch series of the three patchset?

[PATCH v2 0/2] extend kexec_file_load system call
[PATCH v5 00/13] kexec_file_load implementation for PowerPC
[PATCH v2 0/6] kexec_file: Add buffer hand-over for the next kernel

Do they depend on other patches?

Thanks
Dave

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

Re: [PATCH v2 0/6] kexec_file: Add buffer hand-over for the next kernel

[Thiago Jung Bauermann]

Hello Dave,

Am Mittwoch, 17 August 2016, 10:52:26 schrieb Dave Young:
> On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote:
> > This series applies on top of v5 of the "kexec_file_load implementation
> > for PowerPC" patch series (which applies on top of v4.8-rc1):
> > 
> > https://lists.infradead.org/pipermail/kexec/2016-August/016843.html
> 
> I'm trying to review your patches, but seems I can not apply them
> cleanly to mainline kernel or v4.8-rc1

Strange, I just did a test using the patches I received via the kexec 
mailing list, and git am applied them cleanly on v4.8-rc1.

> Apply the kexec_file_load series failed as below on v4.8-rc1:
> 
> Applying: kexec_file: Allow arch-specific memory walking for
> kexec_add_buffer
> error: patch failed: include/linux/kexec.h:149
> error: include/linux/kexec.h: patch does not apply
> Patch failed at 0001 kexec_file: Allow arch-specific memory walking for
> kexec_add_buffer
> The copy of the patch that failed is found in: .git/rebase-apply/patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
> 
> What is the order of your patch series of the three patchset?
> 
> [PATCH v2 0/2] extend kexec_file_load system call
> [PATCH v5 00/13] kexec_file_load implementation for PowerPC
> [PATCH v2 0/6] kexec_file: Add buffer hand-over for the next kernel

Yes, that is correct.

> Do they depend on other patches?

No, they apply directly on v4.8-rc1.

I just published a branch with the patches, if you want you can use that 
instead. The branch is called kexec-patches and is at the repo 
g...@github.com:bauermann/linux

-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center


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