[PATCH 2/2] sadump: fix wrong progress report on sadump formats

[HATAYAMA Daisuke]

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 <d.hatayama at jp.fujitsu.com>
---
 sadump_info.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/sadump_info.c b/sadump_info.c
index 8716167..5ff5595 100644
--- a/sadump_info.c
+++ b/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
-- 
1.9.3