Discussion:
[Makedumpfile PATCH V3] elf_info: fix file_size if segment is excluded
Pratyush Anand
2017-05-10 04:32:59 UTC
Permalink
I received following on a specific x86_64 hp virtual machine while
executing `makedumpfile --mem-usage /proc/kcore`.

vtop4_x86_64: Can't get a valid pte.
readmem: Can't convert a virtual address(ffffffff88115860) to physical address.
readmem: type_addr: 0, addr:ffffffff88115860, size:128
get_nodes_online: Can't get the node online map.

With some debug print in vtop4_x86_64() I noticed that pte value is read
as 0, while crash reads the value correctly:

from makedumpfile:
vaddr=ffffffff88115860
page_dir=59eaff8
pml4=59ed067
pgd_paddr=59edff0
pgd_pte=59ee063
pmd_paddr=59ee200
pmd_pte=3642f063
pte_paddr=3642f8a8
pte=0

from crash
crash> vtop ffffffff88115860
VIRTUAL PHYSICAL
ffffffff88115860 5b15860

PML4 DIRECTORY: ffffffff87fea000
PAGE DIRECTORY: 59ed067
PUD: 59edff0 => 59ee063
PMD: 59ee200 => 3642f063
PTE: 3642f8a8 => 5b15163
PAGE: 5b15000

With some more debug prints in elf_info.c

Before calling exclude_segment()

LOAD (2)
phys_start : 100000
phys_end : dfffd000
virt_start : ffff8a5a40100000
virt_end : ffff8a5b1fffd000
file_offset: a5a40102000
file_size : dfefd000

exclude_segment() is called for Crash Kernel whose range is
2b000000-350fffff.

We see following after exclude_segment()

LOAD (2)
phys_start : 100000
phys_end : 2affffff
virt_start : ffff8a5a40100000
virt_end : ffff8a5a6affffff
file_offset: a5a40102000
file_size : dfefd000
LOAD (3)
phys_start : 35100000
phys_end : dfffd000
virt_start : ffff8a5a75100000
virt_end : ffff8a5b1fffd000
file_offset: a5a75102000
file_size : 0

Since file_size is calculated wrong therefore readpage_elf() does not
behave correctly.

This patch fixes above wrong behavior.

Signed-off-by: Pratyush Anand <***@redhat.com>
---
v1->v2 : subtracted (end - start) from file_size as well
v2->v3 : subtracted (end - start) for boundary cases as well.
elf_info.c | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/elf_info.c b/elf_info.c
index 8e2437622141..2c58359a438f 100644
--- a/elf_info.c
+++ b/elf_info.c
@@ -826,9 +826,12 @@ static int exclude_segment(struct pt_load_segment **pt_loads,
temp_seg.virt_end = vend;
temp_seg.file_offset = (*pt_loads)[i].file_offset
+ temp_seg.virt_start - (*pt_loads)[i].virt_start;
+ temp_seg.file_size = temp_seg.phys_end
+ - temp_seg.phys_start;

(*pt_loads)[i].virt_end = kvstart - 1;
(*pt_loads)[i].phys_end = start - 1;
+ (*pt_loads)[i].file_size -= temp_seg.file_size;

tidx = i+1;
} else if (kvstart != vstart) {
@@ -838,6 +841,7 @@ static int exclude_segment(struct pt_load_segment **pt_loads,
(*pt_loads)[i].phys_start = end + 1;
(*pt_loads)[i].virt_start = kvend + 1;
}
+ (*pt_loads)[i].file_size -= (end -start);
}
}
/* Insert split load segment, if any. */
--
2.9.3
Atsushi Kumagai
2017-05-17 07:45:22 UTC
Permalink
Hello Pratyush,

Sorry for late reply.
I have no further comment for now, but the current --mem-usage
seems have some problems. I can't decide that this patch is insufficient or
that's quite a different matter now, so please let me defer acknowledgment
for a while.

Thanks,
Atsushi Kumagai
Post by Pratyush Anand
I received following on a specific x86_64 hp virtual machine while
executing `makedumpfile --mem-usage /proc/kcore`.
vtop4_x86_64: Can't get a valid pte.
readmem: Can't convert a virtual address(ffffffff88115860) to physical address.
readmem: type_addr: 0, addr:ffffffff88115860, size:128
get_nodes_online: Can't get the node online map.
With some debug print in vtop4_x86_64() I noticed that pte value is read
vaddr=ffffffff88115860
page_dir=59eaff8
pml4=59ed067
pgd_paddr=59edff0
pgd_pte=59ee063
pmd_paddr=59ee200
pmd_pte=3642f063
pte_paddr=3642f8a8
pte=0
from crash
crash> vtop ffffffff88115860
VIRTUAL PHYSICAL
ffffffff88115860 5b15860
PML4 DIRECTORY: ffffffff87fea000
PAGE DIRECTORY: 59ed067
PUD: 59edff0 => 59ee063
PMD: 59ee200 => 3642f063
PTE: 3642f8a8 => 5b15163
PAGE: 5b15000
With some more debug prints in elf_info.c
Before calling exclude_segment()
LOAD (2)
phys_start : 100000
phys_end : dfffd000
virt_start : ffff8a5a40100000
virt_end : ffff8a5b1fffd000
file_offset: a5a40102000
file_size : dfefd000
exclude_segment() is called for Crash Kernel whose range is
2b000000-350fffff.
We see following after exclude_segment()
LOAD (2)
phys_start : 100000
phys_end : 2affffff
virt_start : ffff8a5a40100000
virt_end : ffff8a5a6affffff
file_offset: a5a40102000
file_size : dfefd000
LOAD (3)
phys_start : 35100000
phys_end : dfffd000
virt_start : ffff8a5a75100000
virt_end : ffff8a5b1fffd000
file_offset: a5a75102000
file_size : 0
Since file_size is calculated wrong therefore readpage_elf() does not
behave correctly.
This patch fixes above wrong behavior.
---
v1->v2 : subtracted (end - start) from file_size as well
v2->v3 : subtracted (end - start) for boundary cases as well.
elf_info.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/elf_info.c b/elf_info.c
index 8e2437622141..2c58359a438f 100644
--- a/elf_info.c
+++ b/elf_info.c
@@ -826,9 +826,12 @@ static int exclude_segment(struct pt_load_segment **pt_loads,
temp_seg.virt_end = vend;
temp_seg.file_offset = (*pt_loads)[i].file_offset
+ temp_seg.virt_start - (*pt_loads)[i].virt_start;
+ temp_seg.file_size = temp_seg.phys_end
+ - temp_seg.phys_start;
(*pt_loads)[i].virt_end = kvstart - 1;
(*pt_loads)[i].phys_end = start - 1;
+ (*pt_loads)[i].file_size -= temp_seg.file_size;
tidx = i+1;
} else if (kvstart != vstart) {
@@ -838,6 +841,7 @@ static int exclude_segment(struct pt_load_segment **pt_loads,
(*pt_loads)[i].phys_start = end + 1;
(*pt_loads)[i].virt_start = kvend + 1;
}
+ (*pt_loads)[i].file_size -= (end -start);
}
}
/* Insert split load segment, if any. */
--
2.9.3
Pratyush Anand
2017-05-30 15:48:01 UTC
Permalink
Hi Atsushi,
Post by Atsushi Kumagai
Hello Pratyush,
Sorry for late reply.
I have no further comment for now, but the current --mem-usage
seems have some problems. I can't decide that this patch is insufficient or
that's quite a different matter now, so please let me defer acknowledgment
for a while.
Any decision on this patch.

Thanks

~Pratyush
Atsushi Kumagai
2017-05-31 00:49:00 UTC
Permalink
Post by Pratyush Anand
Hi Atsushi,
Post by Atsushi Kumagai
Hello Pratyush,
Sorry for late reply.
I have no further comment for now, but the current --mem-usage
seems have some problems. I can't decide that this patch is insufficient or
that's quite a different matter now, so please let me defer acknowledgment
for a while.
Any decision on this patch.
The problem I met is still unresolved, but it occurs even without this patch.
So I accept this patch for now.


Thanks,
Atsushi Kumagai
Pratyush Anand
2017-05-31 01:12:04 UTC
Permalink
Post by Atsushi Kumagai
Post by Pratyush Anand
Hi Atsushi,
Post by Atsushi Kumagai
Hello Pratyush,
Sorry for late reply.
I have no further comment for now, but the current --mem-usage
seems have some problems. I can't decide that this patch is insufficient or
that's quite a different matter now, so please let me defer acknowledgment
for a while.
Any decision on this patch.
The problem I met is still unresolved, but it occurs even without this patch.
So I accept this patch for now.
Thanks.

~Pratyush
Pratyush Anand
2017-06-28 03:45:51 UTC
Permalink
Hi Atsushi,
Post by Atsushi Kumagai
Post by Pratyush Anand
Hi Atsushi,
Post by Atsushi Kumagai
Hello Pratyush,
Sorry for late reply.
I have no further comment for now, but the current --mem-usage
seems have some problems. I can't decide that this patch is insufficient or
that's quite a different matter now, so please let me defer acknowledgment
for a while.
Any decision on this patch.
The problem I met is still unresolved, but it occurs even without this patch.
So I accept this patch for now.
This patch is missing in your devel branch.

Just a gentle reminder, so that it does not miss 1.6.2.

Thanks


Pratyush
Atsushi Kumagai
2017-06-29 00:13:52 UTC
Permalink
Post by Pratyush Anand
Hi Atsushi,
Post by Atsushi Kumagai
Post by Pratyush Anand
Hi Atsushi,
Post by Atsushi Kumagai
Hello Pratyush,
Sorry for late reply.
I have no further comment for now, but the current --mem-usage
seems have some problems. I can't decide that this patch is insufficient or
that's quite a different matter now, so please let me defer acknowledgment
for a while.
Any decision on this patch.
The problem I met is still unresolved, but it occurs even without this patch.
So I accept this patch for now.
This patch is missing in your devel branch.
Just a gentle reminder, so that it does not miss 1.6.2.
Thank you for informing me, I pushed it.

Thanks,
Atsushi Kumagai

Loading...