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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility




[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux