linux-kernel - Re: [bug] mm/slab.c boot crash in -git, "kernel BUG at mm/slab.c:2103!"

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:	Tue, 15 Apr 2008 12:03:05 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Mel Gorman <mel@....ul.ie>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	linux-kernel@...r.kernel.org, Christoph Lameter <clameter@....com>,
	Nick Piggin <npiggin@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Yinghai.Lu@....com
Subject: Re: [bug] mm/slab.c boot crash in -git, "kernel BUG at
	mm/slab.c:2103!"


* Mel Gorman <mel@....ul.ie> wrote:

> [    0.000000] Warning only 4GB will be used.
> [    0.000000] Use a HIGHMEM64G enabled kernel.
> [    0.000000] Entering add_active_range(0, 0, 1048576) 0 entries of 256 used
> 
> It's recognised and only memory below 4GB is registered and it's all 
> on node 0. However, I do note that it also registers all the holes as 
> valid memory. The memory should never get freed because it should be 
> reserved during boot by reserve_bootmem() but it still raises an 
> eyebrow.

32-bit does memory_present() calls to register all RAM - and those calls 
are correct (they do not include holes) and the resulting sparse memory 
section layout looks correct, and all the mem_map[] chunk allocations 
succeed as well.

furthermore, when freeing memory from bootmem allocator into the buddy 
allocator we consult the e820 map again via a page_is_ram() call, so we 
make sure holes do not end up in the memory map and in the free page 
pool. (all rounded to section boundaries of course)

> [    0.000000] early_node_map[1] active PFN ranges
> [    0.000000]     0:        0 ->  1048576
> [    0.000000] On node 0 totalpages: 1048576
> [    0.000000]   DMA zone: 32 pages used for memmap
> [    0.000000]   DMA zone: 0 pages reserved
> [    0.000000]   DMA zone: 4064 pages, LIFO batch:0
> [    0.000000]   Normal zone: 1760 pages used for memmap
> [    0.000000]   Normal zone: 223520 pages, LIFO batch:31
> [    0.000000]   HighMem zone: 6400 pages used for memmap
> [    0.000000]   HighMem zone: 812800 pages, LIFO batch:31
> [    0.000000]   Movable zone: 0 pages used for memmap
> 
> And from this, it looks like memmap is getting setup. So far, it looks
> like basic initialisation was ok.

yep. I did a few extra printouts to make sure, but came to the same 
conclusion. The system boots fine with the same config on v2.6.24.

	Ingo
--
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/