Hi Dave,
Dave Anderson wrote:
>>> pfn_to_pos() returns the position of the page header corresponding to
>>> the argument "pfn", and the value can be larger than "int".
>>> So it should be declared as "ulong".
>> Queued for the next release.
>>
>> By the way, did you notice this by code inspection, or did you actually
>> see a failure with a large vmcore? And if you did see it, what kind of error
>> resulted? It appears like it would just read a bogus page descriptor, and
>> that could result in a few different error types. Also, I was under the
>> impression that the compressed diskdump/kdump page descriptors would be located
>> near the beginning of the vmcore, and for one to exist beyond 4GB would be highly
>> unusual?
>
> Hi Ken'ich,
>
> Sorry -- I had not read your response to Takao's makedumpfile patch on the kexec
> list before I responded to this one, so I see it was by code inspection.
>
> Although I'm still curious as to how much physical memory a system would need
> in order for a compressed diskdump/kdump to have a page descriptor that high
> in the vmcore? ;-)
Thank you for a good comment.
I considered this problem carefully after your comment, and an error due
to this problem happens on a system which has 16TB memory. So we cannot
see an error due to this problem currently ;-)
The position, which is returned by pfn_to_pos(), is represented by pfn.
So if its value is larger than "int", a system memory should be larger
than ("int" * page_size). An x86_64 system needs 16TB (= 4G * 4K) memory.
Thanks
Ken'ichi Ohmichi
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
