makedumpfile: support for newer kernels [v4.9 onwards]

[Abhishek Shah]

>>Seeing further, I could see that the "get_mem_map" function at the end
>>[if (!is_xen_memory())]
>>is attempting to change "info->max_mapnr" value based on "mem=" option.
>>-- in particular commit ebe2fa3a5c1e2bfac3778c0fbeca4287a934cc58.
>>And in my kernel command line, "mem=2G" was present, as I intended to
>>take dump of 2G RAM,
>>resulting into reduced "info->max_mapnr".
>
> Basically, this adjusting info->max_mapnr must be harmless since
> it just intends to ignore unused memory regions.
> Did you find out why adjusting info->max_mapnr causes the problem ?
>
Operation of "write_kdump_pages_and_bitmap_cyclic" depends on
info->max_mapnr value.
That is the reason why we have problem with kdump compressed dump, but
not with elf formatted dump.

>From the memory regions that I have, the last region does not seem to
be mapped (which contains the address sought by crash);
because of which, info->max_mapnr is getting adjusted to some reduced
value (compared to the previous info->max_mapnr of 880203).

Following is the memory regions that I have:
mem_map (0)
  mem_map    : ffff8008000c6280
  pfn_start  : 0
  pfn_end    : 40000
mem_map (1)
  mem_map    : 0
  pfn_start  : 40000
  pfn_end    : 80000
mem_map (2)
  mem_map    : 0
  pfn_start  : 80000
  pfn_end    : c0000
mem_map (3)
  mem_map    : 0
  pfn_start  : c0000
  pfn_end    : 100000
mem_map (4)
  mem_map    : 0
  pfn_start  : 100000
  pfn_end    : 140000
mem_map (5)
  mem_map    : 0
  pfn_start  : 140000
  pfn_end    : 180000
mem_map (6)
  mem_map    : 0
  pfn_start  : 180000
  pfn_end    : 1c0000
mem_map (7)
  mem_map    : 0
  pfn_start  : 1c0000
  pfn_end    : 200000
mem_map (8)
  mem_map    : 0
  pfn_start  : 200000
  pfn_end    : 240000
mem_map (9)
  mem_map    : 0
  pfn_start  : 240000
  pfn_end    : 280000
mem_map (10)
  mem_map    : 0
  pfn_start  : 280000
  pfn_end    : 2c0000
mem_map (11)
  mem_map    : 0
  pfn_start  : 2c0000
  pfn_end    : 300000
mem_map (12)
  mem_map    : ffff800045136a80
  pfn_start  : 300000
  pfn_end    : 340000
mem_map (13)
  mem_map    : ffff800046136480
  pfn_start  : 340000
  pfn_end    : 380000
mem_map (14)
  mem_map    : ffff800047136c00
  pfn_start  : 380000
  pfn_end    : 3c0000
mem_map (15)
  mem_map    : 0
  pfn_start  : 3c0000
  pfn_end    : 400000
mem_map (16)
  mem_map    : 0
  pfn_start  : 400000
  pfn_end    : 440000
mem_map (17)
  mem_map    : 0
  pfn_start  : 440000
  pfn_end    : 480000
mem_map (18)
  mem_map    : 0
  pfn_start  : 480000
  pfn_end    : 4c0000
mem_map (19)
  mem_map    : 0
  pfn_start  : 4c0000
  pfn_end    : 500000
mem_map (20)
  mem_map    : 0
  pfn_start  : 500000
  pfn_end    : 540000
mem_map (21)
  mem_map    : 0
  pfn_start  : 540000
  pfn_end    : 580000
mem_map (22)
  mem_map    : 0
  pfn_start  : 580000
  pfn_end    : 5c0000
mem_map (23)
  mem_map    : 0
  pfn_start  : 5c0000
  pfn_end    : 600000
mem_map (24)
  mem_map    : 0
  pfn_start  : 600000
  pfn_end    : 640000
mem_map (25)
  mem_map    : 0
  pfn_start  : 640000
  pfn_end    : 680000
mem_map (26)
  mem_map    : 0
  pfn_start  : 680000
  pfn_end    : 6c0000
mem_map (27)
  mem_map    : 0
  pfn_start  : 6c0000
  pfn_end    : 700000
mem_map (28)
  mem_map    : 0
  pfn_start  : 700000
  pfn_end    : 740000
mem_map (29)
  mem_map    : 0
  pfn_start  : 740000
  pfn_end    : 780000
mem_map (30)
  mem_map    : 0
  pfn_start  : 780000
  pfn_end    : 7c0000
mem_map (31)
  mem_map    : 0
  pfn_start  : 7c0000
  pfn_end    : 800000
mem_map (32)
  mem_map    : 0
  pfn_start  : 800000
  pfn_end    : 840000
mem_map (33)
  mem_map    : 0
  pfn_start  : 840000
  pfn_end    : 880000
mem_map (34)
  mem_map    : 0
  pfn_start  : 880000
  pfn_end    : 880203

>>So, I commented out this portion and confirmed that "info->max_mapnr"
>>remains same
>>throughout. And I was able to get kdump compressed vmcore process-able
>>by crash utility.
>
> This sounds like there are some valid data beyond the adjusted info->max_mapnr,
> is that true ?
I am not sure about it, but crash does look for data in mem_map(34),
I haven't yet look into this in-detail. I will do that soon.


Regards,
Abhishek