Hi Kazu,
HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab(a)nec.com> writes:
Hi Alex,
+cc kexec list (the right one for makedumpfile patch)
Thanks, sorry for the mix up :(
-----Original Message-----
> Whenever the variables compound_order or private become greater than
> 31, left bit-shift of 1 overflows, and nr_pages becomes zero. If nr_pages
> becomes 0 and pages are being excluded at the end of the PFN loop, the
> else branch of the last if statement is entered and pfn is decremented by
> 1 because nr_pages is 0. Finally, this causes the loop variable pfn to
> be assigned the same value as before when the next loop iteration begins
> which results in an infinite loop.
>
> This issue appeared on s390 64bit architecture with a dump of 16GB RAM.
The patch looks good to me, but just out of curiosity, when do the
compound_order or private become greater than 31 on s390?
Thanks,
Kazu
I added some debug statements and this what i got:
compound_order 0
compound_order 1
compound_order 2
compound_order 3
compound_order 4
compound_order 5
compound_order 6
compound_order 7
compound_order 8
private 0
private 1
private 2
private 3
private 4
private 5
private 52
private 6
private 7
private 8
It seems that not compound_order but private is at fault here and
triggers the bug. Not sure yet what that exactly means and whether we
have here another bug which triggers this one :/
Regards
Alex