[PATCH] makedumpfile: fix max_mapnr issue on system has over 44-bit addressing

[Jingbai Ma]

On 09/25/2013 04:39 PM, HATAYAMA Daisuke wrote:
> (2013/09/25 17:16), Jingbai Ma wrote:
> <cut>
>>>
>>>> @@ -5153,10 +5160,11 @@ write_kdump_header(void)
>>>> * Write common header
>>>> */
>>>> strncpy(dh->signature, KDUMP_SIGNATURE, strlen(KDUMP_SIGNATURE));
>>>> - dh->header_version = 5;
>>>> + dh->header_version = 6;
>>>> dh->block_size = info->page_size;
>>>> dh->sub_hdr_size = sizeof(kh) + size_note;
>>>> dh->sub_hdr_size = divideup(dh->sub_hdr_size, dh->block_size);
>>>> + /* dh->max_mapnr may be truncated here, full 64bit in kh.max_mapnr */
>>>> dh->max_mapnr = info->max_mapnr;
>>>
>>> dh->max_mapnr = MIN(info->max_mapnr, UINT_MAX) seems better for old
>>> versions of crash utitlity.
>>>
>>
>> Although change this value to UINT_MAX doesn't help the old crash
>> utility very much. At least this special value will tell the user
>> something happened.
>> Will fix it.
>>
>>
>
> This is the largest page frame number old crash utilities can represent,
> not special value.
> By this, old crash utilities can read at least the pages less than
> UINT_MAX,
> which is better than making dh->max_mapnr overflow; then dh->max_mapnr
> would typically become
> a small number.
>

I knew, but crash utility may still report reading page error before its 
command prompt.
Anyway, UINT_MAX has a better chance to make old utility happy, so I 
will fix it. :)

-- 
Thanks,
Jingbai Ma