linux-kernel - Re: x86/mm: Limit 2/4M size calculation to x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5003156B.2090301@canonical.com>
Date:	Sun, 15 Jul 2012 12:09:31 -0700
From:	Stefan Bader <stefan.bader@...onical.com>
To:	Yinghai Lu <yinghai@...nel.org>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	WANG Cong <xiyou.wangcong@...il.com>, Tejun Heo <tj@...nel.org>
Subject: Re: x86/mm: Limit 2/4M size calculation to x86_32

On 07/13/2012 11:12 AM, Yinghai Lu wrote:
> On Fri, Jul 13, 2012 at 6:41 AM, Stefan Bader
> <stefan.bader@...onical.com> wrote:
>> I was bisecting a problem on 64bit where any attempt to cause a crash kernel to
>> boot would hang. The bisect ended up on commit 722bc6b (x86/mm: Fix the size
>> calculation of mapping tables) and somehow, looking at the calling function and
>> the ranges printed on boot, I think the calculations should only be done in the
>> 32bit case.
>>
>> On 64bit:
>> [    0.000000] init_memory_mapping: [mem 0x00000000-0x77e87fff]
>> [    0.000000]  [mem 0x00000000-0x77dfffff] page 2M
>> [    0.000000]  [mem 0x77e00000-0x77e87fff] page 4k
>>
>> Attached patch would fix this if you agree with it. Thanks.
>
> it does not look like for the hang for your system. maybe just because
> it change a bit memblock allocation layout.
>
The hang is merely the effect of limited memory getting even more limited and 
running out of it while trying to uncompress your initramfs and/or kernel is not 
helping.

> can you please post whole boot log that is working and not?
>
I am traveling this week and have no access to the machine. But basically you 
can see the issue relatively simple. As 64bit does not have the first 2/4M area 
as 4k pages. So with the current state of the patch this would allocate extra 
space of about 3MB for the first range  (about 1.9GB).
Again the problem is not something bad going on beyond the fact that it wastes 
memory and it just happens to be more than it used to be, so the memory set 
aside for getting it to boot suddenly failed to be enough.

-Stefan
> Thanks
>
> Yinghai
>


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/