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

*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

Post by Baoquan He
---
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

Baoquan He

2016-10-11 07:41:11 UTC

Hi Eric,

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

*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

Dave Young

2016-10-11 08:19:21 UTC

Post by Baoquan He
Hi Eric,
Thanks a lot for your reviewing! Sorry for late reply.

*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

Dave Young

2016-10-11 08:43:24 UTC

Post by Baoquan He
Hi Eric,
Thanks a lot for your reviewing! Sorry for late reply.

*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?

Post by Dave Young
Thanks
Dave
_______________________________________________
kexec mailing list
http://lists.infradead.org/mailman/listinfo/kexec

Baoquan He

2016-10-12 00:26:13 UTC

Post by Baoquan He
Hi Eric,
Thanks a lot for your reviewing! Sorry for late reply.

*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

Pratyush Anand

2016-10-12 09:09:45 UTC

Post by Dave Young
PAGE_OFFSET can be get via vaddr - paddr from elf pt_loads so only

Post by Dave Young
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

Baoquan He

2016-10-13 08:53:14 UTC

Hi Pratyush,

Post by Pratyush Anand

Post by Dave Young
PAGE_OFFSET can be get via vaddr - paddr from elf pt_loads so only

Post by Dave Young
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

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

Post by Pratyush Anand
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

Dave Young

2016-10-14 03:13:04 UTC

Post by Baoquan He
Hi Pratyush,

Post by Pratyush Anand

Post by Dave Young
PAGE_OFFSET can be get via vaddr - paddr from elf pt_loads so only

Post by Dave Young
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

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.

Post by Baoquan He
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

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

Thanks
Dave

Dave Young

2016-11-01 05:10:19 UTC

Post by 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 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(-)
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 <***@google.com>
Date: Tue Oct 11 13:55:08 2016 -0700

kdump, vmcoreinfo: report memory sections virtual addresses
[snip]]

Post by Baoquan He
}
/* 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.

Post by Baoquan He
#ifdef CONFIG_HUGETLB_PAGE
VMCOREINFO_NUMBER(HUGETLB_PAGE_DTOR);
#endif
--
2.5.5
_______________________________________________
kexec mailing list
http://lists.infradead.org/mailman/listinfo/kexec

Thanks
Dave

Baoquan He

2016-11-01 05:33:53 UTC

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?

Post by Dave Young
commit 0549a3c02efb350776bc869685a361045efd3a29
Date: Tue Oct 11 13:55:08 2016 -0700
kdump, vmcoreinfo: report memory sections virtual addresses
[snip]]

Moving KERNEL_IMAGE_SIZE to x86 should be a standalone patch.
I remember Dave Anderson said he use it in crash utility, cced him.

Thanks
Dave

Dave Anderson

2016-11-01 14:13:34 UTC

----- Original Message -----

Post by 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 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(-)
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);

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

Post by Dave Young
commit 0549a3c02efb350776bc869685a361045efd3a29
Date: Tue Oct 11 13:55:08 2016 -0700
kdump, vmcoreinfo: report memory sections virtual addresses
[snip]]

Moving KERNEL_IMAGE_SIZE to x86 should be a standalone patch.
I remember Dave Anderson said he use it in crash utility, cced him.

Thanks
Dave

Baoquan He

2016-11-02 01:34:33 UTC

Hi Dave,

Post by Dave Anderson

Post by Dave Young
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?

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

Dave Anderson

2016-11-02 13:29:48 UTC

----- Original Message -----

Post by Baoquan He
Hi Dave,

Post by Dave Anderson

Post by Dave Young
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?

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

Baoquan He

2016-11-02 13:48:25 UTC

Post by Dave Anderson
----- Original Message -----

Post by Baoquan He
Hi Dave,

Post by Dave Anderson