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 _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
