linux-kernel - Re: unable to handle kernel paging request at 40000000 __alloc_memory_core

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]

Date:	Sat, 10 Jul 2010 10:14:10 +0200
From:	Conny Seidel <conny.seidel@....com>
To:	Yinghai Lu <yinghai@...nel.org>
CC:	"Petkov, Borislav" <Borislav.Petkov@....com>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: unable to handle kernel paging request at 40000000
 __alloc_memory_core_early+0x147/0x1d6

On Fri, 9 Jul 2010 21:03:42 -0400
Yinghai Lu <yinghai@...nel.org> wrote:

>On 07/09/2010 04:51 PM, Conny Seidel wrote:
>> On Fri, 9 Jul 2010 18:07:50 -0400
>> Yinghai Lu <yinghai@...nel.org> wrote:
>>
>>> On 07/09/2010 01:42 PM, Conny Seidel wrote:
>>>> sparse_early_mem_map_alloc: sparsemem memory map backing failed some
>>>> memory will not be available.
>>>
>>> please check
>>>
>> This still panics, see logfile for complete trace.
>>
>
>this one should fix the problem.
>
>Thanks
>
>Yinghai

Yes, Patch -v3 fixes the issue, thanks.

>[PATCH -v3] x86,nobootmem: make alloc_bootmem_node fall back to other node when 32bit numa are used
>
>Borislav Petkov <borislav.petkov@....com> reported his 32bit numa has problem:
>
>[    0.000000] Reserving total of 4c00 pages for numa KVA remap
>[    0.000000] kva_start_pfn ~ 32800 max_low_pfn ~ 375fe
>[    0.000000] max_pfn = 238000
>[    0.000000] 8202MB HIGHMEM available.
>[    0.000000] 885MB LOWMEM available.
>[    0.000000]   mapped low ram: 0 - 375fe000
>[    0.000000]   low ram: 0 - 375fe000
>[    0.000000] alloc (nid=8 100000 - 7ee00000) (1000000 - ffffffff) 1000 1000 => 34e7000
>[    0.000000] alloc (nid=8 100000 - 7ee00000) (1000000 - ffffffff) 200 40 => 34c9d80
>[    0.000000] alloc (nid=0 100000 - 7ee00000) (1000000 - ffffffffffffffff) 180 40 => 34e6140
>[    0.000000] alloc (nid=1 80000000 - c7e60000) (1000000 - ffffffffffffffff) 240 40 => 80000000
>[    0.000000] BUG: unable to handle kernel paging request at 40000000
>[    0.000000] IP: [<c2c8cff1>] __alloc_memory_core_early+0x147/0x1d6
>[    0.000000] *pdpt = 0000000000000000 *pde = f000ff53f000ff00
>...
>[    0.000000] Call Trace:
>[    0.000000]  [<c2c8b4f8>] ? __alloc_bootmem_node+0x216/0x22f
>[    0.000000]  [<c2c90c9b>] ? sparse_early_usemaps_alloc_node+0x5a/0x10b
>[    0.000000]  [<c2c9149e>] ? sparse_init+0x1dc/0x499
>[    0.000000]  [<c2c79118>] ? paging_init+0x168/0x1df
>[    0.000000]  [<c2c780ff>] ? native_pagetable_setup_start+0xef/0x1bb
>
>looks like it allocate much high address for bootmem.
>
>try to cut limit with get_max_mapped()
>
>-v3: make alloc_bootmem_node could fallback to other node.
>     just like old alloc_bootmem_node did
>
>need this patch for 2.6.34 and 2.6.35
>
>Reported-by: Borislav Petkov <borislav.petkov@....com>
>Signed-off-by: Yinghai Lu <yinghai@...nel.org>
>Cc: stable@...nel.org

Tested-by: Conny Seidel <conny.seidel@....com>

##
##################################################################
# Email : conny.seidel@....com            GnuPG-Key : 0xA6AB055D #
# Fingerprint: 17C4 5DB2 7C4C C1C7 1452 8148 F139 7C09 A6AB 055D #
##################################################################
# Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach      #
# General Managers: Alberto Bozzo, Andrew Bowd                   #
# Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen #
#               HRB Nr. 43632                                    #
##################################################################

Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)