[PATCH 0/3] makedumpfile-1.0.6: Fix the ELF dumpfile

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Ken'ichi Ohmichi wrote:

>
> I think that the crash utility should be able to read the difference
> from p_filesz to p_memsz as zero pages, and I created the attached
> patch for it. What do you think this patch?
>
> Example of excluding zero pages:
>   makedumpfile created the ELF dumpfile with excluding zero pages.
>
> * Result of "readelf -a"
>   The zero pages of some LOAD segments are excluded, and the LOAD
>   segments are separated. The excluded pages are:
>     0xffff81000072d000 - 0xffff810001000000
>     0xffff81000ad05000 - 0xffff81000ed05000
>     0xffff81000ed6f000 - 0xffff810037e6e000
>     0xffff810037ff0000 - 0xffff8100cff60000
>     0xffff8100cff69000 - 0xffff8100cff70000
>     0xffff810100000000 - 0xffff810129c00000
>     0xffff810129c46000 - 0xffff81012a000000
>     0xffff8101659b9000 - 0xffff810165b6c000
>     0xffff81016ff00000 - 0xffff810170000000
>
>   - vmcore
>     Program Headers:
>       Type           Offset             VirtAddr           PhysAddr
>                      FileSiz            MemSiz              Flags  Align
>       NOTE           0x0000000000000190 0x0000000000000000 0x0000000000000000
>                      0x0000000000000590 0x0000000000000590         0
>       LOAD           0x0000000000000720 0xffffffff80000000 0x0000000000200000
>                      0x000000000052d000 0x000000000052d000  RWE    0
>       LOAD           0x000000000052d720 0xffff810000000000 0x0000000000000000
>                      0x00000000000a0000 0x00000000000a0000  RWE    0
>       LOAD           0x00000000005cd720 0xffff810000100000 0x0000000000100000
>                      0x0000000000f00000 0x0000000000f00000  RWE    0
>       LOAD           0x00000000014cd720 0xffff810005000000 0x0000000005000000
>                      0x00000000caf70000 0x00000000caf70000  RWE    0
>       LOAD           0x00000000cc43d720 0xffff810100000000 0x0000000100000000
>                      0x0000000070000000 0x0000000070000000  RWE    0
>
>   - The ELF dumpfile(excluding zero pages)
>     Program Headers:
>       Type           Offset             VirtAddr           PhysAddr
>                      FileSiz            MemSiz              Flags  Align
>       NOTE           0x00000000000002e0 0x0000000000000000 0x0000000000000000
>                      0x0000000000000590 0x0000000000000590         0
>       LOAD           0x0000000000000870 0xffffffff80000000 0x0000000000200000
>                      0x000000000052d000 0x000000000052d000  RWE    0
>       LOAD           0x000000000052d870 0xffff810000000000 0x0000000000000000
>                      0x000000000009f000 0x00000000000a0000  RWE    0
>       LOAD           0x00000000005cc870 0xffff810000100000 0x0000000000100000
>                      0x000000000062d000 0x0000000000f00000  RWE    0
>       LOAD           0x0000000000bf9870 0xffff810005000000 0x0000000005000000
>                      0x0000000005d05000 0x0000000009d05000  RWE    0
>       LOAD           0x00000000068fe870 0xffff81000ed05000 0x000000000ed05000
>                      0x000000000006a000 0x0000000029169000  RWE    0
>       LOAD           0x0000000006968870 0xffff810037e6e000 0x0000000037e6e000
>                      0x0000000000182000 0x00000000980f2000  RWE    0
>       LOAD           0x0000000006aea870 0xffff8100cff60000 0x00000000cff60000
>                      0x0000000000009000 0x0000000000010000  RWE    0
>       LOAD           0x0000000006af3870 0xffff810100000000 0x0000000100000000
>                      0x0000000000000000 0x0000000029c00000  RWE    0
>       LOAD           0x0000000006af3870 0xffff810129c00000 0x0000000129c00000
>                      0x0000000000046000 0x0000000000400000  RWE    0
>       LOAD           0x0000000006b39870 0xffff81012a000000 0x000000012a000000
>                      0x000000003b9b9000 0x000000003bb6c000  RWE    0
>       LOAD           0x00000000424f2870 0xffff810165b6c000 0x0000000165b6c000
>                      0x000000000a394000 0x000000000a494000  RWE    0
>
> * Result of gdb/crash
>   gdb can read the excluded page of virtual-address 0xffff81000072d000,
>   but the crash utility can not read this page.
>   - vmcore
>     (gdb) x/8 0xffff81000072d000
>     0xffff81000072d000:     0x00000000      0x00000000      0x00000000      0x00000000
>     0xffff81000072d010:     0x00000000      0x00000000      0x00000000      0x00000000
>     (gdb)
>
>     crash> rd 0xffff81000072d000 4
>     ffff81000072d000:  0000000000000000 0000000000000000   ................
>     ffff81000072d010:  0000000000000000 0000000000000000   ................
>     crash>
>
>   - The ELF dumpfile(excluding zero pages)
>     (gdb) x/8 0xffff81000072d000
>     0xffff81000072d000:     0x00000000      0x00000000      0x00000000      0x00000000
>     0xffff81000072d010:     0x00000000      0x00000000      0x00000000      0x00000000
>     (gdb)
>
>     crash> rd 0xffff81000072d000 4
>     rd: read error: kernel virtual address: ffff81000072d000  type: "64-bit KVADDR"
>     crash>
>
>     the crash utility with attached patch:
>     crash> rd 0xffff81000072d000 4
>     ffff81000072d000:  0000000000000000 0000000000000000   ................
>     ffff81000072d010:  0000000000000000 0000000000000000   ................
>     crash>
>
> Thanks
> Ken'ichi Ohmichi
>

Hi Ken'ichi,

We're headed in the right direction... this new scheme can certainly
be handled.

However, in your crash utility patch, I don't understand why it's necessary
to do all those calculations in read_netdump()?

Every read_netdump() request has a "cnt" value equal to or less than
a page-size, and the request can never cross a page boundary.  So the
the requested block of data is either completely contained in the dumpfile,
or is completely *not* contained in the dumpfile.

So the question is simply whether the request falls inside the new
"zero-fill" region of makedumpfile ELF vmcores.

Netdump and diskdump ELF vmcores have p->filesz and p->memsz
that are guaranteed to be equal, and in all kdump ELF vmcores I've
seen to date, those two fields have always been equal.

Currently the crash utility's "pls->phys_end" value is based upon the
PT_LOAD's p->filesz value, which in the makedumpfile ELF case may
be smaller than the p->memsz value.

Wouldn't it be easier to create a additional per-segment "pls->zero_fill" field
that is based upon the (possibly) larger p->memsz value?  Then, if the request
does not fall into the (pls->phys_start <= startaddr < pls->phys_end) range,
a subsequent check can be made to see if it falls within the alternative
(pls->phys_end <= startaddr < pls->zero_fill) range?  If that's true,
then we can just return a block of zeroes.

Dave








[Netdev]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]     [Linux Media]     [Linux Resources]

Powered by Linux