Hi Kazu, HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab@xxxxxxx> 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/crash-utility
