kexec: Export memory sections virtual addresses to vmcoreinfo
Subsystems (4)
PATCH 1/1 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.
--- arch/x86/kernel/machine_kexec_64.c | 4 ++++ kernel/kexec_core.c | 3 --- 2 files changed, 4 insertions(+), 3 deletions(-)
arch/x86/kernel/machine_kexec_64.c +4 -0
@@ -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 */
kernel/kexec_core.c +0 -3
@@ -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
Signature · 7 lines
2.5.5 _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
Quoted 10 lines · Baoquan He
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 usingVMCOREINFO_NUMBERwe can reuse the existing structnumber_tablein makedumpfile to import data easily.Since they are related to
x86_64only, put them intoarch_crash_save_vmcoreinfo. And move the exportion ofKERNEL_IMAGE_SIZEtogether since it's also forx86_64only.
*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
Quoted 36 lines
Signed-off-by Baoquan He <[email protected]>--- arch/x86/kernel/machine_kexec_64.c | 4 ++++ kernel/kexec_core.c | 3 --- 2 files changed, 4 insertions(+), 3 deletions(-)arch/x86/kernel/machine_kexec_64.c +4
-0@@ -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 */ kernel/kexec_core.c +0
-3@@ -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
Hi Eric,
Thanks a lot for your reviewing! Sorry for late reply.
Quoted 13 lines · Eric W. Biederman
Quoted 10 lines · Baoquan He
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 usingVMCOREINFO_NUMBERwe can reuse the existing structnumber_tablein makedumpfile to import data easily.Since they are related to
x86_64only, put them intoarch_crash_save_vmcoreinfo. And move the exportion ofKERNEL_IMAGE_SIZEtogether since it's also forx86_64only.
Quoted 7 lines
*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
Quoted 37 lines · Baoquan He
Hi Eric,
Thanks a lot for your reviewing! Sorry for late reply.
Quoted 13 lines · Eric W. Biederman
Quoted 10 lines · Baoquan He
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 usingVMCOREINFO_NUMBERwe can reuse the existing structnumber_tablein makedumpfile to import data easily.Since they are related to
x86_64only, put them intoarch_crash_save_vmcoreinfo. And move the exportion ofKERNEL_IMAGE_SIZEtogether since it's also forx86_64only.Quoted 7 lines
*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 ofPAGE_OFFSET, VMALLOC and VMEMMAP are fixed, makedumpfile also hard codes them.In kexec-tools, we try to get
page_offset_basefrom/proc/kallsymsor search it from/proc/kcoreelf header with the help of virtual address of symbol_stext. Then we save it intop_vaddrof 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.
Quoted 1 line
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
Quoted 38 lines · Dave Young
Quoted 37 lines · Baoquan He
Hi Eric,
Thanks a lot for your reviewing! Sorry for late reply.
Quoted 13 lines · Eric W. Biederman
Quoted 10 lines · Baoquan He
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 usingVMCOREINFO_NUMBERwe can reuse the existing structnumber_tablein makedumpfile to import data easily.Since they are related to
x86_64only, put them intoarch_crash_save_vmcoreinfo. And move the exportion ofKERNEL_IMAGE_SIZEtogether since it's also forx86_64only.Quoted 7 lines
*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 ofPAGE_OFFSET, VMALLOC and VMEMMAP are fixed, makedumpfile also hard codes them.In kexec-tools, we try to get
page_offset_basefrom/proc/kallsymsor search it from/proc/kcoreelf header with the help of virtual address of symbol_stext. Then we save it intop_vaddrof 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.
Quoted 4 lines
Quoted 1 line
So it's necessary to add them into VMCOREINFO to let makedumpfile know.
PAGE_OFFSETcan be get via vaddr - paddr from elfpt_loadsso onlyVMALLOC_BASEandVMEMMAP_BASEis necessary..
Besides of these, since kernel module is randomized as well I wonder if it need special handling, does it work?
Quoted 8 lines
Thanks
Dave_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 38 lines · Dave Young
Quoted 37 lines · Baoquan He
Hi Eric,
Thanks a lot for your reviewing! Sorry for late reply.
Quoted 13 lines · Eric W. Biederman
Quoted 10 lines · Baoquan He
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 usingVMCOREINFO_NUMBERwe can reuse the existing structnumber_tablein makedumpfile to import data easily.Since they are related to
x86_64only, put them intoarch_crash_save_vmcoreinfo. And move the exportion ofKERNEL_IMAGE_SIZEtogether since it's also forx86_64only.Quoted 7 lines
*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 ofPAGE_OFFSET, VMALLOC and VMEMMAP are fixed, makedumpfile also hard codes them.In kexec-tools, we try to get
page_offset_basefrom/proc/kallsymsor search it from/proc/kcoreelf header with the help of virtual address of symbol_stext. Then we save it intop_vaddrof 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.
Quoted 4 lines
Quoted 1 line
So it's necessary to add them into VMCOREINFO to let makedumpfile know.
PAGE_OFFSETcan be get via vaddr - paddr from elfpt_loadsso onlyVMALLOC_BASEandVMEMMAP_BASEis 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
Quoted 4 lines · Baoquan He
Quoted 2 lines
PAGE_OFFSETcan be get via vaddr - paddr from elfpt_loadsso onlyQuoted 1 line
VMALLOC_BASEandVMEMMAP_BASEis 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
Hi Pratyush,
Quoted 11 lines · Pratyush Anand
Quoted 4 lines · Baoquan He
Quoted 2 lines
PAGE_OFFSETcan be get via vaddr - paddr from elfpt_loadsso onlyQuoted 1 line
VMALLOC_BASEandVMEMMAP_BASEis 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_OFFSETthen, probably you do not need to know anything else.
Quoted 6 lines
I think, we can simplify makedumpfile code, where we do not need to depend on
VMALLOC_STARTorVMEMMAP_STARTetc."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."
Check makedumpfile code and re-think about this, it's really like you said, we can convert VA to PA by swapper_pg_dir or init_level4_pgt. But the reason why we have to involve VMALLOC_START and VMEMMAP_START is that in x86_64 direct mapping and kernel text mapping are all linear mapping. Linear mapping can let us do a very efficient translation from VA to PA. Especially for page filtering, we need get PA of mm related data. All of them need convert by swapper_pg_dir or init_level4_pgt, that's inefficient, imagine the current system usually own many Tera bytes of physical memory.
So here though we can pick up crash memory regions from elf program header of vmcore and calculate the PAGE_OFFSET, we still need VMALLOC_START and VMEMMAP_START.
Thanks
Baoquan
Quoted 6 lines
In fact, I have cleanup patches for ARM64 [1], which take above approach and get rid of need of
VMALLOC_STARTorVMEMMAP_STARTetc. I will be sending them upstream soon.
Quoted 6 lines
Probably, x86 can take the similar approach.
~Pratyush
[1] https://github.com/pratyushanand/makedumpfile/blob/arm64_devel/arch/arm64.c#L228
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 21 lines · Baoquan He
Hi Pratyush,
Quoted 11 lines · Pratyush Anand
Quoted 4 lines · Baoquan He
Quoted 2 lines
PAGE_OFFSETcan be get via vaddr - paddr from elfpt_loadsso onlyQuoted 1 line
VMALLOC_BASEandVMEMMAP_BASEis 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_OFFSETthen, probably you do not need to know anything else.Quoted 6 lines
I think, we can simplify makedumpfile code, where we do not need to depend on
VMALLOC_STARTorVMEMMAP_STARTetc."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."
Quoted 10 lines
Check makedumpfile code and re-think about this, it's really like you said, we can convert VA to PA by
swapper_pg_dirorinit_level4_pgt. But the reason why we have to involveVMALLOC_STARTandVMEMMAP_STARTis that inx86_64direct mapping and kernel text mapping are all linear mapping. Linear mapping can let us do a very efficient translation from VA to PA. Especially for page filtering, we need get PA of mm related data. All of them need convert byswapper_pg_dirorinit_level4_pgt, that's inefficient, imagine the current system usually own many Tera bytes of physical memory.
Atsushi, what do you think about above concern? Ideally we should do it in userspace instead of add more symbols. Maybe do a test on large memory machine is necessary.
Quoted 16 lines
So here though we can pick up crash memory regions from elf program header of vmcore and calculate the
PAGE_OFFSET, we still needVMALLOC_STARTandVMEMMAP_START.Thanks
BaoquanQuoted 10 lines
In fact, I have cleanup patches for ARM64 [1], which take above approach and get rid of need of
VMALLOC_STARTorVMEMMAP_STARTetc. I will be sending them upstream soon.Probably, x86 can take the similar approach.
~Pratyush
Quoted 7 lines
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Thanks
Dave
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 22 lines · Baoquan He
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 usingVMCOREINFO_NUMBERwe can reuse the existing structnumber_tablein makedumpfile to import data easily.Since they are related to
x86_64only, put them intoarch_crash_save_vmcoreinfo. And move the exportion ofKERNEL_IMAGE_SIZEtogether since it's also forx86_64only.Signed-off-by Baoquan He <[email protected]>--- arch/x86/kernel/machine_kexec_64.c | 4 ++++ kernel/kexec_core.c | 3 --- 2 files changed, 4 insertions(+), 3 deletions(-)arch/x86/kernel/machine_kexec_64.c +0
-0
arch/x86/kernel/machine_kexec_64.c void arch_crash_save_vmcoreinfo(void) · line 343
Quoted 7 lines
arch/x86/kernel/machine_kexec_64.c +4
-0@@ -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 );
Pratyush has posted makedumpfile patches below to avoid the VMCOREINFO:
http://lists.infradead.org/pipermail/kexec/2016-October/017540.html
But we have this in mainline which also introduced the VMCOREINFO numbers, can you send a patch to revert them?
commit 0549a3c02efb350776bc869685a361045efd3a29
Author: Thomas Garnier <[email protected]> Date: Tue Oct 11 13:55:08 2016 -0700
kdump, vmcoreinfo: report memory sections virtual addresses
[snip]]
Quoted 8 lines
arch/x86/kernel/machine_kexec_64.c +0
-0}/* arch-dependent functionality related to kexec file-based syscall */ kernel/kexec_core.c +0
-0
kernel/kexec_core.c static int __init crash_save_vmcoreinfo_init(void) · line 1472
Quoted 6 lines
kernel/kexec_core.c +0
-3@@ -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
Moving KERNEL_IMAGE_SIZE to x86 should be a standalone patch. I remember Dave Anderson said he use it in crash utility, cced him.
Quoted 11 lines
kernel/kexec_core.c +0
-0#ifdef CONFIG_HUGETLB_PAGE VMCOREINFO_NUMBER (HUGETLB_PAGE_DTOR );#endif Signature · 7 lines
2.5.5 _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
Thanks
Dave
Quoted 34 lines · Dave Young
Quoted 22 lines · Baoquan He
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 usingVMCOREINFO_NUMBERwe can reuse the existing structnumber_tablein makedumpfile to import data easily.Since they are related to
x86_64only, put them intoarch_crash_save_vmcoreinfo. And move the exportion ofKERNEL_IMAGE_SIZEtogether since it's also forx86_64only.Signed-off-by Baoquan He <[email protected]>--- arch/x86/kernel/machine_kexec_64.c | 4 ++++ kernel/kexec_core.c | 3 --- 2 files changed, 4 insertions(+), 3 deletions(-)arch/x86/kernel/machine_kexec_64.c +0
-0arch/x86/kernel/machine_kexec_64.c void arch_crash_save_vmcoreinfo(void) · line 343
Quoted 7 lines
arch/x86/kernel/machine_kexec_64.c +4
-0@@ -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 );Pratyush has posted makedumpfile patches below to avoid the VMCOREINFO:
http://lists.infradead.org/pipermail/kexec/2016-October/017540.html
Quoted 2 lines
But we have this in mainline which also introduced the VMCOREINFO numbers, can you send a patch to revert them?
OK, will do.
However for find_vmemmap_x86_64() in makedumpfile, vmemmap_start is still needed. I checked code, seems no better way to avoid. I am not sure how many people are really using "-e" option to exclude unused vmemmap pages.
Maybe just leave it as is, and fix it when people complain?
Quoted 39 lines
commit
0549a3c02efb350776bc869685a361045efd3a29Author: Thomas Garnier <[email protected]> Date: Tue Oct 11 13:55:08 2016 -0700kdump, vmcoreinfo: report memory sections virtual addresses
[snip]]Quoted 8 lines
arch/x86/kernel/machine_kexec_64.c +0
-0}/* arch-dependent functionality related to kexec file-based syscall */ kernel/kexec_core.c +0
-0kernel/kexec_core.c static int __init crash_save_vmcoreinfo_init(void) · line 1472
Quoted 6 lines
kernel/kexec_core.c +0
-3@@ -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 Moving
KERNEL_IMAGE_SIZEto x86 should be a standalone patch. I remember Dave Anderson said he use it in crash utility, cced him.Quoted 11 lines
kernel/kexec_core.c +0
-0#ifdef CONFIG_HUGETLB_PAGE VMCOREINFO_NUMBER (HUGETLB_PAGE_DTOR );#endif Signature · 7 lines
2.5.5 _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexecThanks
Dave
----- Original Message -----
Quoted 39 lines · Dave Young
Quoted 35 lines · Baoquan He
Quoted 23 lines
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 usingVMCOREINFO_NUMBERwe can reuse the existing structnumber_tablein makedumpfile to import data easily.Since they are related to
x86_64only, put them intoarch_crash_save_vmcoreinfo. And move the exportion ofKERNEL_IMAGE_SIZEtogether since it's also forx86_64only.Signed-off-by Baoquan He <[email protected]>--- arch/x86/kernel/machine_kexec_64.c | 4 ++++ kernel/kexec_core.c | 3 --- 2 files changed, 4 insertions(+), 3 deletions(-)arch/x86/kernel/machine_kexec_64.c +0
-0arch/x86/kernel/machine_kexec_64.c void arch_crash_save_vmcoreinfo(void) · line 343
Quoted 7 lines
arch/x86/kernel/machine_kexec_64.c +4
-0@@ -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 );Pratyush has posted makedumpfile patches below to avoid the VMCOREINFO:
http://lists.infradead.org/pipermail/kexec/2016-October/017540.htmlQuoted 2 lines
But we have this in mainline which also introduced the VMCOREINFO numbers, can you send a patch to revert them?
Quoted 8 lines
OK, will do.
However for
find_vmemmap_x86_64()in makedumpfile,vmemmap_startis still needed. I checked code, seems no better way to avoid. I am not sure how many people are really using "-e" option to exclude unused vmemmap pages.Maybe just leave it as is, and fix it when people complain?
Speaking of complaints, is there any chance you can make the x86_64 "phys_base" value available? The VMCOREINFO_SYMBOL(phys_base) is useless since its contents are needed in order to access the symbol address.
Dave
Quoted 33 lines
Quoted 33 lines
commit
0549a3c02efb350776bc869685a361045efd3a29Author: Thomas Garnier <[email protected]> Date: Tue Oct 11 13:55:08 2016 -0700kdump, vmcoreinfo: report memory sections virtual addresses
[snip]]Quoted 8 lines
arch/x86/kernel/machine_kexec_64.c +0
-0}/* arch-dependent functionality related to kexec file-based syscall */ kernel/kexec_core.c +0
-0kernel/kexec_core.c static int __init crash_save_vmcoreinfo_init(void) · line 1472
Quoted 6 lines
kernel/kexec_core.c +0
-3@@ -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 Moving
KERNEL_IMAGE_SIZEto x86 should be a standalone patch. I remember Dave Anderson said he use it in crash utility, cced him.Quoted 7 lines
kernel/kexec_core.c +0
-1#ifdef CONFIG_HUGETLB_PAGE VMCOREINFO_NUMBER (HUGETLB_PAGE_DTOR );#endif --2.5.5
Quoted 8 lines
Quoted 7 lines
Quoted 4 lines
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexecThanks
Dave
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Hi Dave,
Quoted 12 lines · Dave Anderson
Quoted 12 lines
Quoted 4 lines
But we have this in mainline which also introduced the VMCOREINFO numbers, can you send a patch to revert them?
OK, will do.
However for
find_vmemmap_x86_64()in makedumpfile,vmemmap_startis still needed. I checked code, seems no better way to avoid. I am not sure how many people are really using "-e" option to exclude unused vmemmap pages.
Quoted 6 lines
Quoted 1 line
Maybe just leave it as is, and fix it when people complain?
Speaking of complaints, is there any chance you can make the
x86_64"phys_base" value available? TheVMCOREINFO_SYMBOL(phys_base)is useless since its contents are needed in order to access the symbol address.
Yeah, the current exporting of virt addr of phys_base is really useless for x86_64. While I saw you have got phys_base from kdump-ed vmcore elf program header since kexec-tools has created that pt_load for kernel text region.
machdep->machspec->phys_base = phdr->p_paddr - (phdr->p_vaddr & ~(__START_KERNEL_map));
Do you still want the value of phys_base? If yes, I can change it to export the real value of phys_base, not &phys_base.
In fact, exporting &phys_base was done in 2008, makedumpfile has taken the similar way you use in crash to get value of phys_base. Means it has been ignored very earlier. You could be the first person to complain about it.
Thanks
Baoquan
----- Original Message -----
Quoted 30 lines
Hi Dave,
Quoted 12 lines · Dave Anderson
Quoted 12 lines
Quoted 4 lines
But we have this in mainline which also introduced the VMCOREINFO numbers, can you send a patch to revert them?
OK, will do.
However for
find_vmemmap_x86_64()in makedumpfile,vmemmap_startis still needed. I checked code, seems no better way to avoid. I am not sure how many people are really using "-e" option to exclude unused vmemmap pages.Quoted 6 lines
Quoted 1 line
Maybe just leave it as is, and fix it when people complain?
Speaking of complaints, is there any chance you can make the
x86_64"phys_base" value available? TheVMCOREINFO_SYMBOL(phys_base)is useless since its contents are needed in order to access the symbol address.Yeah, the current exporting of virt addr of
phys_baseis really useless forx86_64. While I saw you have gotphys_basefrom kdump-ed vmcore elf program header since kexec-tools has created thatpt_loadfor kernel text region.
machdep->machspec->phys_base=phdr->p_paddr- (phdr->p_vaddr& ~(__START_KERNEL_map));
Quoted 7 lines
Do you still want the value of
phys_base? If yes, I can change it to export the real value ofphys_base, not&phys_base.In fact, exporting
&phys_basewas done in 2008, makedumpfile has taken the similar way you use in crash to get value ofphys_base. Means it has been ignored very earlier. You could be the first person to complain about it.
No, this is not the first time it's been brought up. Anyway, yes, it would be preferable if it were readily available in vmcoreinfo rather than depending upon the PT_LOAD semantics.
Thanks,
Dave
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 36 lines · Dave Anderson
----- Original Message -----
Quoted 33 lines
Hi Dave,
Quoted 12 lines · Dave Anderson
Quoted 12 lines
Quoted 4 lines
But we have this in mainline which also introduced the VMCOREINFO numbers, can you send a patch to revert them?
OK, will do.
However for
find_vmemmap_x86_64()in makedumpfile,vmemmap_startis still needed. I checked code, seems no better way to avoid. I am not sure how many people are really using "-e" option to exclude unused vmemmap pages.Quoted 6 lines
Quoted 1 line
Maybe just leave it as is, and fix it when people complain?
Speaking of complaints, is there any chance you can make the
x86_64"phys_base" value available? TheVMCOREINFO_SYMBOL(phys_base)is useless since its contents are needed in order to access the symbol address.Yeah, the current exporting of virt addr of
phys_baseis really useless forx86_64. While I saw you have gotphys_basefrom kdump-ed vmcore elf program header since kexec-tools has created thatpt_loadfor kernel text region.
machdep->machspec->phys_base=phdr->p_paddr- (phdr->p_vaddr& ~(__START_KERNEL_map));Do you still want the value of
phys_base? If yes, I can change it to export the real value ofphys_base, not&phys_base.
Quoted 8 lines
Quoted 4 lines
In fact, exporting
&phys_basewas done in 2008, makedumpfile has taken the similar way you use in crash to get value ofphys_base. Means it has been ignored very earlier. You could be the first person to complain about it.No, this is not the first time it's been brought up. Anyway, yes, it would be preferable if it were readily available in vmcoreinfo rather than depending upon the
PT_LOADsemantics.
All right, I need move KERNEL_IMAGE_SIZE to x86 64. Can change it in the same patch. Will CC you when post.
Thanks
Baoquan