From 3883607bb61b265e9de259722b247075f7710994 Mon Sep 17 00:00:00 2001 From: HATAYAMA Daisuke Date: Mon, 20 Jun 2016 15:00:53 +0900 Subject: [PATCH 2/2] [PATCH 2/2] sadump: fix wrong progress report on sadump formats Currently, makedumpfile displays wrong progress report on sadump formats and could result in "Floating point exception" in the worst case: Original pages : 0x0000000000000000 Excluded pages : 0x0000000001f2b44a Pages filled with zero : 0x0000000000b160b5 Non-private cache pages : 0x0000000000007a7e Private cache pages : 0x0000000000000431 User process data pages : 0x000000000140d4dc Free pages : 0x0000000000000000 Hwpoison pages : 0x000000000000000a Remaining pages : 0xfffffffffe0d4bb6 Floating point exception (core dumped) This is because on sadump-related formats, the number of memory hole pages is not counted, the number of original pages becomes 0 and zero division exception occurs below: 9409void 9410print_report(void) 9411{ 9412 mdf_pfn_t pfn_original, pfn_excluded, shrinking; 9413 9414 /* 9415 * /proc/vmcore doesn't contain the memory hole area. 9416 */ 9417 pfn_original = info->max_mapnr - pfn_memhole; 9418 9419 pfn_excluded = pfn_zero + pfn_cache + pfn_cache_private 9420 + pfn_user + pfn_free + pfn_hwpoison; 9421 shrinking = (pfn_original - pfn_excluded) * 100; 9422 shrinking = shrinking / pfn_original; <-- Here. This commit fixes this issue by counting the number of memory hole pages and so the number of original pages. As a result, makedumpfile displays correct progress report on sadump formats and doesn't exit abnormally: Original pages : 0x0000000001ffaa23 Excluded pages : 0x0000000001f2b44a Pages filled with zero : 0x0000000000b160b5 Non-private cache pages : 0x0000000000007a7e Private cache pages : 0x0000000000000431 User process data pages : 0x000000000140d4dc Free pages : 0x0000000000000000 Hwpoison pages : 0x000000000000000a Remaining pages : 0x00000000000cf5d9 (The number of pages is reduced to 2%.) Memory Hole : 0x00000000000a55dd -------------------------------------------------- Total pages : 0x00000000020a0000 Cache hit: 1570176, miss: 12997082, hit rate: 10.8% Signed-off-by: HATAYAMA Daisuke Signed-off-by: Baoquan He --- sadump_info.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/makedumpfile-1.6.0/sadump_info.c b/makedumpfile-1.6.0/sadump_info.c index 8716167..5ff5595 100644 --- a/makedumpfile-1.6.0/sadump_info.c +++ b/makedumpfile-1.6.0/sadump_info.c @@ -213,6 +213,8 @@ sadump_copy_1st_bitmap_from_memory(void) char buf[si->sh_memory->block_size]; off_t offset_page; unsigned long bitmap_offset, bitmap_len; + mdf_pfn_t pfn, pfn_bitmap1; + extern mdf_pfn_t pfn_memhole; bitmap_offset = si->sub_hdr_offset + sh->block_size*sh->sub_hdr_size; bitmap_len = sh->block_size * sh->bitmap_blocks; @@ -250,6 +252,13 @@ sadump_copy_1st_bitmap_from_memory(void) offset_page += sizeof(buf); } + pfn_bitmap1 = 0; + for (pfn = 0; pfn < info->max_mapnr; ++pfn) { + if (sadump_is_ram(pfn)) + pfn_bitmap1++; + } + pfn_memhole = info->max_mapnr - pfn_bitmap1; + /* * kdump uses the first 640kB on the 2nd kernel. But both * bitmaps should reflect the 1st kernel memory situation. We -- 2.5.5