Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1496504 > unrolled thread

[PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

Back to article view | Back to linux.kernel

Contents

  [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo Baoquan He <bhe@redhat.com> - 2016-10-06 11:40 +0200
    Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo ebiederm@xmission.com (Eric W. Biederman) - 2016-10-06 22:20 +0200
      Re: [PATCH] kexec: Export memory sections virtual addresses to  vmcoreinfo Baoquan He <bhe@redhat.com> - 2016-10-11 09:50 +0200
        Re: [PATCH] kexec: Export memory sections virtual addresses to  vmcoreinfo Dave Young <dyoung@redhat.com> - 2016-10-11 10:20 +0200
          Re: [PATCH] kexec: Export memory sections virtual addresses to  vmcoreinfo Dave Young <dyoung@redhat.com> - 2016-10-11 10:50 +0200
          Re: [PATCH] kexec: Export memory sections virtual addresses to  vmcoreinfo Baoquan He <bhe@redhat.com> - 2016-10-12 02:30 +0200
            Re: [PATCH] kexec: Export memory sections virtual addresses to  vmcoreinfo Pratyush Anand <panand@redhat.com> - 2016-10-12 11:20 +0200

#1496504 — [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

KASLR memory randomization can randomize the base of the physical memory
mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap
(VMEMMAP_START). These need be exported to VMCOREINFO so that user space
utility, mainly makedumpfile can use them to identify the base of each
memory section. Here using VMCOREINFO_NUMBER we can reuse the existing
struct number_table in makedumpfile to import data easily.

Since they are related to x86_64 only, put them into
arch_crash_save_vmcoreinfo. And move the exportion of KERNEL_IMAGE_SIZE
together since it's also for x86_64 only.

Signed-off-by: Baoquan He <bhe@redhat.com>
---
 arch/x86/kernel/machine_kexec_64.c | 4 ++++
 kernel/kexec_core.c                | 3 ---
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index 5a294e4..e150dd7 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -337,6 +337,10 @@ void arch_crash_save_vmcoreinfo(void)
 #endif
 	vmcoreinfo_append_str("KERNELOFFSET=%lx\n",
 			      kaslr_offset());
+	VMCOREINFO_NUMBER(KERNEL_IMAGE_SIZE);
+	VMCOREINFO_NUMBER(PAGE_OFFSET);
+	VMCOREINFO_NUMBER(VMALLOC_START);
+	VMCOREINFO_NUMBER(VMEMMAP_START);
 }
 
 /* arch-dependent functionality related to kexec file-based syscall */
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 5616755..8ad3a29e 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -1467,9 +1467,6 @@ static int __init crash_save_vmcoreinfo_init(void)
 #endif
 	VMCOREINFO_NUMBER(PG_head_mask);
 	VMCOREINFO_NUMBER(PAGE_BUDDY_MAPCOUNT_VALUE);
-#ifdef CONFIG_X86
-	VMCOREINFO_NUMBER(KERNEL_IMAGE_SIZE);
-#endif
 #ifdef CONFIG_HUGETLB_PAGE
 	VMCOREINFO_NUMBER(HUGETLB_PAGE_DTOR);
 #endif
-- 
2.5.5

[toc] | [next] | [standalone]

#1496844

Baoquan He <bhe@redhat.com> writes:

> KASLR memory randomization can randomize the base of the physical memory
> mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap
> (VMEMMAP_START). These need be exported to VMCOREINFO so that user space
> utility, mainly makedumpfile can use them to identify the base of each
> memory section. Here using VMCOREINFO_NUMBER we can reuse the existing
> struct number_table in makedumpfile to import data easily.
>
> Since they are related to x86_64 only, put them into
> arch_crash_save_vmcoreinfo. And move the exportion of KERNEL_IMAGE_SIZE
> together since it's also for x86_64 only.

*Scratches my head*  I would have thought this information would have
better fit in the ELF header.  Where it actually has a field for virtual
address.  It also has a field for physical address, and a third field
for offset in the file (which is where the kdump finds these things in
memory aftewards).

Why do we need need more magic vmcoreinfo to handle this?

Eric

 
>
> Signed-off-by: Baoquan He <bhe@redhat.com>
> ---
>  arch/x86/kernel/machine_kexec_64.c | 4 ++++
>  kernel/kexec_core.c                | 3 ---
>  2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
> index 5a294e4..e150dd7 100644
> --- a/arch/x86/kernel/machine_kexec_64.c
> +++ b/arch/x86/kernel/machine_kexec_64.c
> @@ -337,6 +337,10 @@ void arch_crash_save_vmcoreinfo(void)
>  #endif
>  	vmcoreinfo_append_str("KERNELOFFSET=%lx\n",
>  			      kaslr_offset());
> +	VMCOREINFO_NUMBER(KERNEL_IMAGE_SIZE);
> +	VMCOREINFO_NUMBER(PAGE_OFFSET);
> +	VMCOREINFO_NUMBER(VMALLOC_START);
> +	VMCOREINFO_NUMBER(VMEMMAP_START);
>  }
>  
>  /* arch-dependent functionality related to kexec file-based syscall */
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 5616755..8ad3a29e 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -1467,9 +1467,6 @@ static int __init crash_save_vmcoreinfo_init(void)
>  #endif
>  	VMCOREINFO_NUMBER(PG_head_mask);
>  	VMCOREINFO_NUMBER(PAGE_BUDDY_MAPCOUNT_VALUE);
> -#ifdef CONFIG_X86
> -	VMCOREINFO_NUMBER(KERNEL_IMAGE_SIZE);
> -#endif
>  #ifdef CONFIG_HUGETLB_PAGE
>  	VMCOREINFO_NUMBER(HUGETLB_PAGE_DTOR);
>  #endif

[toc] | [prev] | [next] | [standalone]

#1498644 — Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

Hi Eric,

Thanks a lot for your reviewing! Sorry for late reply.

On 10/06/16 at 03:07pm, Eric W. Biederman wrote:
> Baoquan He <bhe@redhat.com> writes:
> 
> > KASLR memory randomization can randomize the base of the physical memory
> > mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap
> > (VMEMMAP_START). These need be exported to VMCOREINFO so that user space
> > utility, mainly makedumpfile can use them to identify the base of each
> > memory section. Here using VMCOREINFO_NUMBER we can reuse the existing
> > struct number_table in makedumpfile to import data easily.
> >
> > Since they are related to x86_64 only, put them into
> > arch_crash_save_vmcoreinfo. And move the exportion of KERNEL_IMAGE_SIZE
> > together since it's also for x86_64 only.
> 
> *Scratches my head*  I would have thought this information would have
> better fit in the ELF header.  Where it actually has a field for virtual
> address.  It also has a field for physical address, and a third field
> for offset in the file (which is where the kdump finds these things in
> memory aftewards).
> 
> Why do we need need more magic vmcoreinfo to handle this?

Previously in x86_64, values of PAGE_OFFSET, VMALLOC and VMEMMAP are
fixed, makedumpfile also hard codes them.

In kexec-tools, we try to get page_offset_base from /proc/kallsyms or
search it from /proc/kcore elf header with the help of virtual address
of symbol _stext. Then we save it into p_vaddr of kernel text program
segment. In kdump kernel, we may assume kernel text has the biggest
starting virtual address and search it from vmcore elf header. But I
can't think of a way to get the starting virtual address of vmalloc and
vmemmap which are necessary for makedumpfile analysis.

So it's necessary to add them into VMCOREINFO to let makedumpfile know.

Thanks
Baoquan

[toc] | [prev] | [next] | [standalone]

#1498657 — Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

On 10/11/16 at 03:41pm, Baoquan He wrote:
> Hi Eric,
> 
> Thanks a lot for your reviewing! Sorry for late reply.
> 
> On 10/06/16 at 03:07pm, Eric W. Biederman wrote:
> > Baoquan He <bhe@redhat.com> writes:
> > 
> > > KASLR memory randomization can randomize the base of the physical memory
> > > mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap
> > > (VMEMMAP_START). These need be exported to VMCOREINFO so that user space
> > > utility, mainly makedumpfile can use them to identify the base of each
> > > memory section. Here using VMCOREINFO_NUMBER we can reuse the existing
> > > struct number_table in makedumpfile to import data easily.
> > >
> > > Since they are related to x86_64 only, put them into
> > > arch_crash_save_vmcoreinfo. And move the exportion of KERNEL_IMAGE_SIZE
> > > together since it's also for x86_64 only.
> > 
> > *Scratches my head*  I would have thought this information would have
> > better fit in the ELF header.  Where it actually has a field for virtual
> > address.  It also has a field for physical address, and a third field
> > for offset in the file (which is where the kdump finds these things in
> > memory aftewards).
> > 
> > Why do we need need more magic vmcoreinfo to handle this?
> 
> Previously in x86_64, values of PAGE_OFFSET, VMALLOC and VMEMMAP are
> fixed, makedumpfile also hard codes them.
> 
> In kexec-tools, we try to get page_offset_base from /proc/kallsyms or
> search it from /proc/kcore elf header with the help of virtual address
> of symbol _stext. Then we save it into p_vaddr of kernel text program
> segment. In kdump kernel, we may assume kernel text has the biggest
> starting virtual address and search it from vmcore elf header. But I
> can't think of a way to get the starting virtual address of vmalloc and
> vmemmap which are necessary for makedumpfile analysis.
> 
> So it's necessary to add them into VMCOREINFO to let makedumpfile know.

PAGE_OFFSET can be get via vaddr - paddr from elf pt_loads so only
VMALLOC_BASE and VMEMMAP_BASE is necessary..

Thanks
Dave

[toc] | [prev] | [next] | [standalone]

#1498664 — Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

On 10/11/16 at 04:19pm, Dave Young wrote:
> On 10/11/16 at 03:41pm, Baoquan He wrote:
> > Hi Eric,
> > 
> > Thanks a lot for your reviewing! Sorry for late reply.
> > 
> > On 10/06/16 at 03:07pm, Eric W. Biederman wrote:
> > > Baoquan He <bhe@redhat.com> writes:
> > > 
> > > > KASLR memory randomization can randomize the base of the physical memory
> > > > mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap
> > > > (VMEMMAP_START). These need be exported to VMCOREINFO so that user space
> > > > utility, mainly makedumpfile can use them to identify the base of each
> > > > memory section. Here using VMCOREINFO_NUMBER we can reuse the existing
> > > > struct number_table in makedumpfile to import data easily.
> > > >
> > > > Since they are related to x86_64 only, put them into
> > > > arch_crash_save_vmcoreinfo. And move the exportion of KERNEL_IMAGE_SIZE
> > > > together since it's also for x86_64 only.
> > > 
> > > *Scratches my head*  I would have thought this information would have
> > > better fit in the ELF header.  Where it actually has a field for virtual
> > > address.  It also has a field for physical address, and a third field
> > > for offset in the file (which is where the kdump finds these things in
> > > memory aftewards).
> > > 
> > > Why do we need need more magic vmcoreinfo to handle this?
> > 
> > Previously in x86_64, values of PAGE_OFFSET, VMALLOC and VMEMMAP are
> > fixed, makedumpfile also hard codes them.
> > 
> > In kexec-tools, we try to get page_offset_base from /proc/kallsyms or
> > search it from /proc/kcore elf header with the help of virtual address
> > of symbol _stext. Then we save it into p_vaddr of kernel text program
> > segment. In kdump kernel, we may assume kernel text has the biggest
> > starting virtual address and search it from vmcore elf header. But I
> > can't think of a way to get the starting virtual address of vmalloc and
> > vmemmap which are necessary for makedumpfile analysis.
> > 
> > So it's necessary to add them into VMCOREINFO to let makedumpfile know.
> 
> PAGE_OFFSET can be get via vaddr - paddr from elf pt_loads so only
> VMALLOC_BASE and VMEMMAP_BASE is necessary..

Besides of these, since kernel module is randomized as well I wonder if
it need special handling, does it work?

> 
> Thanks
> Dave
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

[toc] | [prev] | [next] | [standalone]

#1499303 — Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

On 10/11/16 at 04:19pm, Dave Young wrote:
> On 10/11/16 at 03:41pm, Baoquan He wrote:
> > Hi Eric,
> > 
> > Thanks a lot for your reviewing! Sorry for late reply.
> > 
> > On 10/06/16 at 03:07pm, Eric W. Biederman wrote:
> > > Baoquan He <bhe@redhat.com> writes:
> > > 
> > > > KASLR memory randomization can randomize the base of the physical memory
> > > > mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap
> > > > (VMEMMAP_START). These need be exported to VMCOREINFO so that user space
> > > > utility, mainly makedumpfile can use them to identify the base of each
> > > > memory section. Here using VMCOREINFO_NUMBER we can reuse the existing
> > > > struct number_table in makedumpfile to import data easily.
> > > >
> > > > Since they are related to x86_64 only, put them into
> > > > arch_crash_save_vmcoreinfo. And move the exportion of KERNEL_IMAGE_SIZE
> > > > together since it's also for x86_64 only.
> > > 
> > > *Scratches my head*  I would have thought this information would have
> > > better fit in the ELF header.  Where it actually has a field for virtual
> > > address.  It also has a field for physical address, and a third field
> > > for offset in the file (which is where the kdump finds these things in
> > > memory aftewards).
> > > 
> > > Why do we need need more magic vmcoreinfo to handle this?
> > 
> > Previously in x86_64, values of PAGE_OFFSET, VMALLOC and VMEMMAP are
> > fixed, makedumpfile also hard codes them.
> > 
> > In kexec-tools, we try to get page_offset_base from /proc/kallsyms or
> > search it from /proc/kcore elf header with the help of virtual address
> > of symbol _stext. Then we save it into p_vaddr of kernel text program
> > segment. In kdump kernel, we may assume kernel text has the biggest
> > starting virtual address and search it from vmcore elf header. But I
> > can't think of a way to get the starting virtual address of vmalloc and
> > vmemmap which are necessary for makedumpfile analysis.
> > 
> > So it's necessary to add them into VMCOREINFO to let makedumpfile know.
> 
> PAGE_OFFSET can be get via vaddr - paddr from elf pt_loads so only
> VMALLOC_BASE and VMEMMAP_BASE is necessary..

Well, yes, I was wrong. I wrongly thought of kernel text virtual address
when I wrote the reply.

So for PAGE_OFFSET we can exclude PT_NOTE and kernel text and calculate
PAGE_OFFSET via vaddr - paddr from crash memory program headers. Surely 
exporting is easier.

Thanks
Baoquan

[toc] | [prev] | [next] | [standalone]

#1499440 — Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

On Wednesday 12 October 2016 05:56 AM, Baoquan He wrote:
>> PAGE_OFFSET can be get via vaddr - paddr from elf pt_loads so only
>> > VMALLOC_BASE and VMEMMAP_BASE is necessary..
> Well, yes, I was wrong. I wrongly thought of kernel text virtual address
> when I wrote the reply

So, if you can get PAGE_OFFSET then, probably you do not need to know 
anything else.

I think, we can simplify makedumpfile code, where we do not need to 
depend on VMALLOC_START or VMEMMAP_START etc.

"If we know PAGE_OFFSET, we can read from swapper space. If we can read 
from swapper space, then we can know PA of any kernel VA, whether it is 
VMALLOC, or vmemmap or module or kernel text area."


In fact, I have cleanup patches for ARM64 [1], which take above approach 
and get rid of need of VMALLOC_START or VMEMMAP_START etc. I will be 
sending them upstream soon.

Probably, x86 can take the similar approach.

~Pratyush

[1] 
https://github.com/pratyushanand/makedumpfile/blob/arm64_devel/arch/arm64.c#L228

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web