Re: [PATCH 1/1] fix left bit-shift overflow in __exclude_unnecessary_pages()

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

 



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




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

 

Powered by Linux