Since the incomplete dump file generated by ENOSPC error can't be analysed by crash utility, but sometimes this file may contain important information and the panic problem won't be reproduced, then we came up with an idea to modify the exist data of the incomplete dump file to make it analysable by crash utility. However, we found it will be more suitable to check the incomplete data than modifying it in make dump file. So, we change the p_filesz of PT_LOAD header, zero_fill and phys_end of PT_LOAD segments, to make crash can analyse incomplete ELF dump file, when incomplete flag exists. the issue was discussed at http://lists.infradead.org/pipermail/kexec/2014-October/012669.html --- a/netdump.c +++ b/netdump.c @@ -52,6 +52,7 @@ static char *vmcoreinfo_read_string(const char *); #define MIN_PAGE_SIZE (4096) +#define DUMP_ELF_INCOMPLETE 0x1 /* * Architectures that have configurable page sizes, * can differ from the host machine's page size. @@ -488,6 +489,10 @@ check_dumpfile_size(char *file) if (stat64(file, &stat) < 0) return; + Elf64_Phdr *load64 = nd->load64; + Elf32_Phdr *load32 = nd->load32; + unsigned int e_flag = (NULL == nd->elf64) ? (nd->elf32)->e_flags : (nd->elf64)->e_flags; + int status = e_flag & DUMP_ELF_INCOMPLETE; for (i = 0; i < nd->num_pt_load_segments; i++) { pls = &nd->pt_load_segments[i]; @@ -495,7 +500,19 @@ check_dumpfile_size(char *file) (pls->phys_end - pls->phys_start); if (segment_end > stat.st_size) { - error(WARNING, "%s: may be truncated or incomplete\n" + if (!status){ + error(WARNING, "%s: may be truncated\n" + " PT_LOAD p_offset: %lld\n" + " p_filesz: %lld\n" + " bytes required: %lld\n" + " dumpfile size: %lld\n\n", + file, pls->file_offset, + pls->phys_end - pls->phys_start, + segment_end, stat.st_size); + return; + } + else{ + error(WARNING, "%s: may be incomplete\n" " PT_LOAD p_offset: %lld\n" " p_filesz: %lld\n" " bytes required: %lld\n" @@ -503,8 +520,25 @@ check_dumpfile_size(char *file) file, pls->file_offset, pls->phys_end - pls->phys_start, segment_end, stat.st_size); - return; + } + if (pls->file_offset > stat.st_size){ + pls->file_offset = 0; + pls->phys_start = 0; + pls->phys_end = 0; + } + else { + if (NULL == load32) + load64->p_filesz = stat.st_size - pls->file_offset; + else + load32->p_filesz = stat.st_size - pls->file_offset; + pls->zero_fill = pls->phys_end; + pls->phys_end = stat.st_size - pls->file_offset + pls->phys_start; + } } + if (NULL == load32) + load64++; + else + load32++; } } -- Crash-utility mailing list Crash-utility(a)redhat.com https://www.redhat.com/mailman/listinfo/crash-utility

A couple notes and questions re: your latest patch: diff --git a/diskdump.c b/diskdump.c index 1d6f7a5..850b174 100644 --- a/diskdump.c +++ b/diskdump.c @@ -999,6 +999,17 @@ cache_page(physaddr_t paddr) if (FLAT_FORMAT()) { if (!read_flattened_format(dd->dfd, pd.offset, dd->compressed_page, pd.size)) return READ_ERROR; What about FLAT_FORMAT()? Should the (is_incomplete_dump()/pd.offset==0) test below be done before the FLAT_FORMAT() check?

+ } else if (is_incomplete_dump()&& (0 == pd.offset)) { Is this how the makedumpfile patch marks pages that have been truncated, i.e., by creating a page_desc_t that has a pd.offset == 0?

+ /* + * if --zero_excluded is specified and incomplete flag is set in dump file, + * zero will be used to fill the lost part. + */ + if (!(*diskdump_flags& ZERO_EXCLUDED)) + return READ_ERROR; + error(WARNING, "%s: data may be lost\n" + " pfn:%lld\n\n" + ,pc->dumpfile,pfn); When --zero_excluded is entered on the crash command line, then the user knows exactly what he is doing, and so there should not be any error/warning messages from the read command itself. A message should only be displayed if debug mode is turned on. For example, this is how it is done currently, but only if debug is set to 8: if (CRASHDEBUG(8)) fprintf(fp, "read_diskdump: zero-fill: " "paddr/pfn: %llx/%lx\n", (ulonglong)paddr, pfn); + memset(dd->compressed_page, 0, dd->block_size); } else { if (lseek(dd->dfd, pd.offset, SEEK_SET) == failed) return SEEK_ERROR; diff --git a/netdump.c b/netdump.c index abc85e0..c8f057e 100644 --- a/netdump.c +++ b/netdump.c @@ -608,7 +608,21 @@ read_netdump(int fd, void *bufptr, int cnt, ulong addr, physaddr_t paddr) "offset: %llx\n", (ulonglong)offset); return SEEK_ERROR; } - if (read(nd->ndfd, bufptr, cnt) != cnt) { + /* + * if --zero_excluded is specified and incomplete flag is set in ELF file, + * zero will be used to fill the lost part. + */ + ssize_t read_ret = read(nd->ndfd, bufptr, cnt); + if (read_ret != cnt) { + if (is_incomplete_dump()&& (read_ret>= 0&& + *diskdump_flags& ZERO_EXCLUDED)) { + error(WARNING, "%s: data may be lost\n" + " offset:%llx\n\n", + pc->dumpfile, offset); Same thing here... if a user enters --zero_excluded on the command line, he should expect strange behavior as a result. Intermingling a bunch of WARNING messages like the one above will only make it more confusing. + bufptr += read_ret; + bzero(bufptr, cnt - read_ret); + return cnt; + } if (CRASHDEBUG(8)) fprintf(fp, "read_netdump: READ_ERROR: " "offset: %llx\n", (ulonglong)offset);