linux-kernel - Re: [bug] SLUB + mm/slab.c boot crash in -rc9

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

* Christoph Lameter <clameter@....com> wrote:

> On Tue, 15 Apr 2008, Linus Torvalds wrote:
> 
> > On Tue, 15 Apr 2008, Ingo Molnar wrote:
> > > 
> > > btw., now with a second full day spent on this regression, i have 
> > > figured out a workaround the hard way: increasing SECTION_SIZE_BITS in 
> > > include/asm-x86/sparsemem.h from 26 to 27 makes it go away.
> > 
> > Interesting.
> 
> Hmmmm. SECTION_SIZE_BITS == 26 means SECTIONS_SHIFT == 6. Increasing 
> SECTION_SIZE_BITS to 27 reduces SECTION_SHIFT to 5. Thereby the number 
> of sparsemem sections (NR_MEM_SECTIONS) is reduced to half (64 to 32).

yes, as i said in this thread already earlier today, the sparse chunking 
goes from 64MB to 128MB. (and hence, by virtue of !PAE having a 4GB 
physical address space, the # of sparse sections goes from 64 to 32 - 
you can see the full sparse sections printout in my latest crashlog in 
my previous mail, including the NR_MEM_SECTIONS printout.)

Pretty please, could you pay more than cursory attention to this bug i 
already spent two full days on and which is blocking the v2.6.25 
release?

Your commits are all over the place in this code, and you are one of the 
maintainers as well. We've got 5000 lines of flux in mm/* in v2.6.25.

I'm just guessing my way around, but right now my impression is that the 
current early memory setup code is unrobust, over-complex, occasionally 
butt-ugly to read code in high need of cleanups, simplifications and 
debug facilities, visibly plagued by hit-and-run changes with frequent 
typos and everything else you normally dont want to see in the core 
kernel. (Did i get your attention now? ;-)

	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/