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 <[email protected]>
---
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
Baoquan He <[email protected]> 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 <[email protected]>
> ---
> 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
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 <[email protected]> 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
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 <[email protected]> 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
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 <[email protected]> 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
> [email protected]
> http://lists.infradead.org/mailman/listinfo/kexec
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 <[email protected]> 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
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
Hi Pratyush,
On 10/12/16 at 02:39pm, Pratyush Anand wrote:
>
>
> 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."
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
>
>
> 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
>
On 10/13/16 at 04:53pm, Baoquan He wrote:
> Hi Pratyush,
>
> On 10/12/16 at 02:39pm, Pratyush Anand wrote:
> >
> >
> > 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."
>
> 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.
>
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.
> 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
> >
> >
> > 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
> >
>
> _______________________________________________
> kexec mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/kexec
Thanks
Dave
On 10/06/16 at 04:46pm, Baoquan He wrote:
> 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 <[email protected]>
> ---
> 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);
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]]
> }
>
> /* 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
Moving KERNEL_IMAGE_SIZE to x86 should be a standalone patch.
I remember Dave Anderson said he use it in crash utility, cced him.
> #ifdef CONFIG_HUGETLB_PAGE
> VMCOREINFO_NUMBER(HUGETLB_PAGE_DTOR);
> #endif
> --
> 2.5.5
>
>
> _______________________________________________
> kexec mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/kexec
Thanks
Dave
On 11/01/16 at 01:10pm, Dave Young wrote:
> On 10/06/16 at 04:46pm, Baoquan He wrote:
> > 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 <[email protected]>
> > ---
> > 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);
>
> 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?
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?
> commit 0549a3c02efb350776bc869685a361045efd3a29
> Author: Thomas Garnier <[email protected]>
> Date: Tue Oct 11 13:55:08 2016 -0700
>
> kdump, vmcoreinfo: report memory sections virtual addresses
> [snip]]
>
> > }
> >
> > /* 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
>
> Moving KERNEL_IMAGE_SIZE to x86 should be a standalone patch.
> I remember Dave Anderson said he use it in crash utility, cced him.
>
> > #ifdef CONFIG_HUGETLB_PAGE
> > VMCOREINFO_NUMBER(HUGETLB_PAGE_DTOR);
> > #endif
> > --
> > 2.5.5
> >
> >
> > _______________________________________________
> > kexec mailing list
> > [email protected]
> > http://lists.infradead.org/mailman/listinfo/kexec
>
> Thanks
> Dave
----- Original Message -----
> On 11/01/16 at 01:10pm, Dave Young wrote:
> > On 10/06/16 at 04:46pm, Baoquan He wrote:
> > > 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 <[email protected]>
> > > ---
> > > 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);
> >
> > 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?
>
> 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?
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
>
> > commit 0549a3c02efb350776bc869685a361045efd3a29
> > Author: Thomas Garnier <[email protected]>
> > Date: Tue Oct 11 13:55:08 2016 -0700
> >
> > kdump, vmcoreinfo: report memory sections virtual addresses
> > [snip]]
> >
> > > }
> > >
> > > /* 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
> >
> > Moving KERNEL_IMAGE_SIZE to x86 should be a standalone patch.
> > I remember Dave Anderson said he use it in crash utility, cced him.
> >
> > > #ifdef CONFIG_HUGETLB_PAGE
> > > VMCOREINFO_NUMBER(HUGETLB_PAGE_DTOR);
> > > #endif
> > > --
> > > 2.5.5
> > >
> > >
> > > _______________________________________________
> > > kexec mailing list
> > > [email protected]
> > > http://lists.infradead.org/mailman/listinfo/kexec
> >
> > Thanks
> > Dave
>
Hi Dave,
On 11/01/16 at 10:13am, Dave Anderson wrote:
>
>
> > > 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?
>
> 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.
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 -----
> Hi Dave,
>
> On 11/01/16 at 10:13am, Dave Anderson wrote:
> >
> >
> > > > 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?
> >
> > 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.
>
> 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.
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
On 11/02/16 at 09:29am, Dave Anderson wrote:
>
>
> ----- Original Message -----
> > Hi Dave,
> >
> > On 11/01/16 at 10:13am, Dave Anderson wrote:
> > >
> > >
> > > > > 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?
> > >
> > > 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.
> >
> > 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.
>
> 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.
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