* [PATCH] [makedumpfile] Fix ELF output with overlapping sections
@ 2007-05-18 10:47 Bernhard Walle
2007-05-31 2:26 ` Ken'ichi Ohmichi
0 siblings, 1 reply; 5+ messages in thread
From: Bernhard Walle @ 2007-05-18 10:47 UTC (permalink / raw)
To: Ken'ichi Ohmichi; +Cc: kexec
I have a core dump with following program headers on IA64:
LOAD 0x0000000000001f4c 0xa000000100000000 0x0000000004000000
0x000000000055c4a0 0x000000000055c4a0 RWE 0
...
LOAD 0x00000000044fc3ec 0xe000000004000000 0x0000000004000000
0x0000000000c92000 0x0000000000c92000 RWE 0
The interesting thing is the overlap in the physical address space.
write_elf_pages() assumes that there's no overlap because it looks only
for the file offset according to the physical start address and silently
assumes that the length matches.
This patch tries to address that problem. At least it works here. Before
I could not read the dump file with `crash' because MAGIC_START was missing
(it's in the 0x4000000 section).
Signed-off-by: Bernhard Walle <bwalle@suse.de>
---
makedumpfile.c | 50 +++++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 45 insertions(+), 5 deletions(-)
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -64,6 +64,43 @@ paddr_to_offset(struct DumpInfo *info, u
return offset;
}
+/**
+ * Sames as paddr_to_offset() but makes sure that the complete range is covered
+ * by the segment
+ */
+off_t
+paddr_to_offset_range(struct DumpInfo *info, unsigned long long paddr, unsigned long len)
+{
+ int i;
+ off_t offset;
+ struct pt_load_segment *pls;
+
+ for (i = offset = 0; i < info->num_load_memory; i++) {
+ pls = &info->pt_load_segments[i];
+ if ((paddr >= pls->phys_start)
+ && (paddr <= pls->phys_end)) {
+
+ /* check the length and also consider adjacent sections */
+ unsigned long long end = pls->phys_end;
+ int j = i+1;
+
+ while (j < info->num_load_memory &&
+ (info->pt_load_segments[j-1].phys_end
+ == info->pt_load_segments[j].phys_start)) {
+ end = info->pt_load_segments[j].phys_end;
+ j++;
+ }
+
+ if (paddr + len <= end) {
+ offset = (off_t)(paddr - pls->phys_start) +
+ pls->file_offset;
+ break;
+ }
+ }
+ }
+ return offset;
+}
+
unsigned long long
vaddr_to_paddr(struct DumpInfo *info, unsigned long long vaddr)
{
@@ -3777,6 +3814,7 @@ write_elf_pages(struct DumpInfo *info)
pfn_end++;
for (pfn = pfn_start; pfn < pfn_end; pfn++) {
+
if (!is_dumpable(&bitmap2, pfn)) {
num_excluded++;
if ((pfn == pfn_end - 1) && frac_tail)
@@ -3934,13 +3972,19 @@ write_elf_pages(struct DumpInfo *info)
goto out;
}
+ if (info->flag_elf64) /* ELF64 */
+ bufsz_remain = load64.p_filesz;
+ else /* ELF32 */
+ bufsz_remain = load32.p_filesz;
+
/*
* Write a PT_LOAD segment.
*/
- off_memory = paddr_to_offset(info, paddr);
+ off_memory = paddr_to_offset_range(info, paddr, bufsz_remain);
if (!off_memory) {
ERRMSG("Can't convert physaddr(%llx) to a offset.\n",
paddr);
+ printf("paddr = 0x%llx, bufsz_remain=%lld\n", paddr, bufsz_remain);
goto out;
}
if (lseek(info->fd_memory, off_memory, SEEK_SET)
@@ -3949,10 +3993,6 @@ write_elf_pages(struct DumpInfo *info)
info->name_memory, strerror(errno));
goto out;
}
- if (info->flag_elf64) /* ELF64 */
- bufsz_remain = load64.p_filesz;
- else /* ELF32 */
- bufsz_remain = load32.p_filesz;
while (bufsz_remain > 0) {
if ((num_dumped % per) == 0)
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] [makedumpfile] Fix ELF output with overlapping sections
2007-05-18 10:47 [PATCH] [makedumpfile] Fix ELF output with overlapping sections Bernhard Walle
@ 2007-05-31 2:26 ` Ken'ichi Ohmichi
2007-05-31 15:18 ` Bernhard Walle
2007-05-31 18:22 ` Bernhard Walle
0 siblings, 2 replies; 5+ messages in thread
From: Ken'ichi Ohmichi @ 2007-05-31 2:26 UTC (permalink / raw)
To: Bernhard Walle; +Cc: kexec
Hi Bernhard,
2007/05/18 12:47:15 +0200, Bernhard Walle <bwalle@suse.de> wrote:
>I have a core dump with following program headers on IA64:
>
> LOAD 0x0000000000001f4c 0xa000000100000000 0x0000000004000000
> 0x000000000055c4a0 0x000000000055c4a0 RWE 0
>...
> LOAD 0x00000000044fc3ec 0xe000000004000000 0x0000000004000000
> 0x0000000000c92000 0x0000000000c92000 RWE 0
>
>The interesting thing is the overlap in the physical address space.
>write_elf_pages() assumes that there's no overlap because it looks only
>for the file offset according to the physical start address and silently
>assumes that the length matches.
Thank you for the patch.
I'm worry that the overlapping spaces may have the same p_filesz.
I think it is certain to check it by p_offset, and created the
attached patch. Please let me know your opinion.
BTW, I don't know the reason why your system's /proc/vmcore has the
overlapping physical address. If you know it, please let me know.
Thanks
Ken'ichi Ohmichi
------------------------------------------------------------
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
---
diff -puN backup/v1.1.3/makedumpfile.c a/makedumpfile.c
--- backup/v1.1.3/makedumpfile.c 2007-04-13 15:44:55.000000000 +0900
+++ a/makedumpfile.c 2007-05-31 11:18:04.000000000 +0900
@@ -2561,6 +2561,33 @@ out:
return ret;
}
+/*
+ * Sames as paddr_to_offset() but makes sure that the specified offset (hint)
+ * in the segment.
+ */
+off_t
+paddr_to_offset2(struct DumpInfo *info, unsigned long long paddr, off_t hint)
+{
+ int i;
+ off_t offset;
+ unsigned long long len;
+ struct pt_load_segment *pls;
+
+ for (i = offset = 0; i < info->num_load_memory; i++) {
+ pls = &info->pt_load_segments[i];
+ len = pls->phys_end - pls->phys_start;
+ if ((paddr >= pls->phys_start)
+ && (paddr < pls->phys_end)
+ && (hint >= pls->file_offset)
+ && (hint < pls->file_offset + len)) {
+ offset = (off_t)(paddr - pls->phys_start) +
+ pls->file_offset;
+ break;
+ }
+ }
+ return offset;
+}
+
unsigned long long
page_to_pfn(struct DumpInfo *info, unsigned long page)
{
@@ -3462,7 +3489,6 @@ write_elf_pages(struct DumpInfo *info)
off_seg_load = info->offset_load_dumpfile;
cd_seg.offset = info->offset_load_dumpfile;
- off_memory = 0;
if (info->flag_elf64) { /* ELF64 */
cd_hdr.offset = sizeof(Elf64_Ehdr) + sizeof(Elf64_Phdr);
@@ -3488,7 +3514,7 @@ write_elf_pages(struct DumpInfo *info)
}
if (load64.p_type != PT_LOAD)
continue;
-
+ off_memory= load64.p_offset;
paddr = load64.p_paddr;
pfn_start = load64.p_paddr / page_size;
pfn_end = (load64.p_paddr+ load64.p_memsz)/page_size;
@@ -3501,6 +3527,7 @@ write_elf_pages(struct DumpInfo *info)
}
if (load32.p_type != PT_LOAD)
continue;
+ off_memory= load32.p_offset;
paddr = load32.p_paddr;
pfn_start = load32.p_paddr / page_size;
pfn_end = (load32.p_paddr+ load32.p_memsz)/page_size;
@@ -3588,7 +3615,7 @@ write_elf_pages(struct DumpInfo *info)
/*
* Write a PT_LOAD segment.
*/
- off_memory = paddr_to_offset(info, paddr);
+ off_memory = paddr_to_offset2(info, paddr, off_memory);
if (!off_memory) {
ERRMSG("Can't convert physaddr(%llx) to a offset.\n",
paddr);
@@ -3680,7 +3707,7 @@ write_elf_pages(struct DumpInfo *info)
/*
* Write a PT_LOAD segment.
*/
- off_memory = paddr_to_offset(info, paddr);
+ off_memory = paddr_to_offset2(info, paddr, off_memory);
if (!off_memory) {
ERRMSG("Can't convert physaddr(%llx) to a offset.\n",
paddr);
_
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] [makedumpfile] Fix ELF output with overlapping sections
2007-05-31 2:26 ` Ken'ichi Ohmichi
@ 2007-05-31 15:18 ` Bernhard Walle
2007-06-01 9:08 ` Ken'ichi Ohmichi
2007-05-31 18:22 ` Bernhard Walle
1 sibling, 1 reply; 5+ messages in thread
From: Bernhard Walle @ 2007-05-31 15:18 UTC (permalink / raw)
To: Ken'ichi Ohmichi; +Cc: kexec
Hello Ken'ichi,
* Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp> [2007-05-31 04:26]:
> 2007/05/18 12:47:15 +0200, Bernhard Walle <bwalle@suse.de> wrote:
> >I have a core dump with following program headers on IA64:
> >
> > LOAD 0x0000000000001f4c 0xa000000100000000 0x0000000004000000
> > 0x000000000055c4a0 0x000000000055c4a0 RWE 0
> >...
> > LOAD 0x00000000044fc3ec 0xe000000004000000 0x0000000004000000
> > 0x0000000000c92000 0x0000000000c92000 RWE 0
> >
> >The interesting thing is the overlap in the physical address space.
> >write_elf_pages() assumes that there's no overlap because it looks only
> >for the file offset according to the physical start address and silently
> >assumes that the length matches.
>
> Thank you for the patch.
> I'm worry that the overlapping spaces may have the same p_filesz.
> I think it is certain to check it by p_offset, and created the
> attached patch. Please let me know your opinion.
>
>
> BTW, I don't know the reason why your system's /proc/vmcore has the
> overlapping physical address. If you know it, please let me know.
thanks for the patch. It looks more safe than my attempt to fix it.
I tested your patch on the machine on which I originally had my
problem. It worked without any problems.
So I vote for applying the patch to your code base. :-)
Thanks,
Bernhard
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] [makedumpfile] Fix ELF output with overlapping sections
2007-05-31 2:26 ` Ken'ichi Ohmichi
2007-05-31 15:18 ` Bernhard Walle
@ 2007-05-31 18:22 ` Bernhard Walle
1 sibling, 0 replies; 5+ messages in thread
From: Bernhard Walle @ 2007-05-31 18:22 UTC (permalink / raw)
To: Ken'ichi Ohmichi; +Cc: kexec
* Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp> [2007-05-31 04:26]:
>
> BTW, I don't know the reason why your system's /proc/vmcore has the
> overlapping physical address. If you know it, please let me know.
/*
* Certain architectures such as x86_64 and ia64 require a separate
* PT_LOAD program header for the kernel. This is controlled through
* info->kern_size.
*
* The separate PT_LOAD program header is required either because the
* kernel is mapped at a different location than the rest of the
* physical memory or because we need to support relocatable kernels.
* Or both as on x86_64.
*
* In the relocatable kernel case this PT_LOAD segment is used to tell
* where the kernel was actually loaded which may be different from
* the load address present in the vmlinux file.
*
* The extra kernel PT_LOAD program header results in a vmcore file
* which is larger than the size of the physical memory. This is
* because the memory for the kernel is present both in the kernel
* PT_LOAD program header and in the physical RAM program headers.
*/
Thanks,
Bernhard
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] [makedumpfile] Fix ELF output with overlapping sections
2007-05-31 15:18 ` Bernhard Walle
@ 2007-06-01 9:08 ` Ken'ichi Ohmichi
0 siblings, 0 replies; 5+ messages in thread
From: Ken'ichi Ohmichi @ 2007-06-01 9:08 UTC (permalink / raw)
To: Bernhard Walle; +Cc: kexec
Hi Bernhard,
2007/05/31 17:18:42 +0200, Bernhard Walle <bwalle@suse.de> wrote:
>* Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp> [2007-05-31 04:26]:
>> 2007/05/18 12:47:15 +0200, Bernhard Walle <bwalle@suse.de> wrote:
>> >I have a core dump with following program headers on IA64:
>> >
>> > LOAD 0x0000000000001f4c 0xa000000100000000 0x0000000004000000
>> > 0x000000000055c4a0 0x000000000055c4a0 RWE 0
>> >...
>> > LOAD 0x00000000044fc3ec 0xe000000004000000 0x0000000004000000
>> > 0x0000000000c92000 0x0000000000c92000 RWE 0
>> >
>> >The interesting thing is the overlap in the physical address space.
>> >write_elf_pages() assumes that there's no overlap because it looks only
>> >for the file offset according to the physical start address and silently
>> >assumes that the length matches.
>>
>> Thank you for the patch.
>> I'm worry that the overlapping spaces may have the same p_filesz.
>> I think it is certain to check it by p_offset, and created the
>> attached patch. Please let me know your opinion.
>>
>>
>> BTW, I don't know the reason why your system's /proc/vmcore has the
>> overlapping physical address. If you know it, please let me know.
>
>thanks for the patch. It looks more safe than my attempt to fix it.
>I tested your patch on the machine on which I originally had my
>problem. It worked without any problems.
>
>So I vote for applying the patch to your code base. :-)
Thank you for the test !
I will merge it.
Thanks
Ken'ichi Ohmichi
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-06-01 9:08 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-05-18 10:47 [PATCH] [makedumpfile] Fix ELF output with overlapping sections Bernhard Walle
2007-05-31 2:26 ` Ken'ichi Ohmichi
2007-05-31 15:18 ` Bernhard Walle
2007-06-01 9:08 ` Ken'ichi Ohmichi
2007-05-31 18:22 ` Bernhard Walle
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.