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: <20080415211359.GA1531@elte.hu>
Date:	Tue, 15 Apr 2008 23:13:59 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Christoph Lameter <clameter@....com>,
	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,
	apw@...dowen.org,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Subject: Re: [bug] SLUB + mm/slab.c boot crash in -rc9


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> > quite. Here are all the successfull bootups from my (failed) 
> > bisection attempt:
> > 
> >  0773769191d943358a8392fa86abd756d004c4b6
> >  21af0297c7e56024a5ccc4d8ad2a590f9ec371ba
> >  26b8256e2bb930a8e4d4d10aa74950d8921376b8
> >  2a10e7c41254941cac87be1eccdcb6379ce097f5
> >  3aa88cdf6bcc9e510c0707581131b821a7d3b7cb
> >  49914084e797530d9baaf51df9eda77babc98fa8
> >  53a6e2342d73d509318836e320f70cd286acd69c
> >  5be3bda8987b12a87863c89b74b136fdb1f072db
> >  6d5f718a497375f853d90247f5f6963368e89803
> >  7272dcd31d56580dee7693c21e369fd167e137fe
> >  77de2c590ec72828156d85fa13a96db87301cc68
> >  82cfbb008572b1a953091ef78f767aa3ca213092
> >  b75f53dba8a4a61fda1ff7e0fb0fe3b0d80e0c64
> >  c087567d3ffb2c7c61e091982e6ca45478394f1a
> >  d4b37ff73540ab90bee57b882a10b21e2f97939f
> >  fde1b3fa947c2512e3715962ebb1d3a6a9b9bb7d
> 
> Ok, can you try this script
> 
> 	git bisect start
> 	git bisect bad 7fa2ac3728ce828070fa3d5846c08157fe5ef431
> 	git bisect good 0773769191d943358a8392fa86abd756d004c4b6
> 	git bisect good 21af0297c7e56024a5ccc4d8ad2a590f9ec371ba
> 	git bisect good 26b8256e2bb930a8e4d4d10aa74950d8921376b8
> 	git bisect good 2a10e7c41254941cac87be1eccdcb6379ce097f5
> 	git bisect good 3aa88cdf6bcc9e510c0707581131b821a7d3b7cb
> 	git bisect good 49914084e797530d9baaf51df9eda77babc98fa8
> 	git bisect good 53a6e2342d73d509318836e320f70cd286acd69c
> 	git bisect good 5be3bda8987b12a87863c89b74b136fdb1f072db
> 	git bisect good 6d5f718a497375f853d90247f5f6963368e89803
> 	git bisect good 7272dcd31d56580dee7693c21e369fd167e137fe
> 	git bisect good 77de2c590ec72828156d85fa13a96db87301cc68
> 	git bisect good 82cfbb008572b1a953091ef78f767aa3ca213092
> 	git bisect good b75f53dba8a4a61fda1ff7e0fb0fe3b0d80e0c64
> 	git bisect good c087567d3ffb2c7c61e091982e6ca45478394f1a
> 	git bisect good d4b37ff73540ab90bee57b882a10b21e2f97939f
> 	git bisect good fde1b3fa947c2512e3715962ebb1d3a6a9b9bb7d
> 
> and then you'll apparently hit that commit you had compile problems 
> with.  HOWEVER, at that point, just do
> 
> 	git bisect visualize
> 
> and pick a commit somewhere roughly half-way that you suspect is a 
> good point of testing, but not near the range that you had problems 
> with.  If you have compile problems in the middle, pick something that 
> is just one third down, for example. It will make the bisection 
> slower, but considering how unable we've been to make much progress 
> other ways, if we can narrow it down from 1874 commits to something 
> smaller, I suspect we'll be much happier.
> 
> Then you just do
> 
> 	git checkout <sha-you-picked-out-here>
> 
> and compile that one, and check. 
> 
> Besides, while the _optimal_ point is half-way, even if you only 
> remove a third or a quarter of the commits at each stage, it's still 
> going to be an exponential thing.

ok, will try that now.

The 'bad' points i posted are definitely well-established as i 
post-validated them them by looking for the slab.c crash pattern in the 
serial logs and looking at the git commit in the bootup signature. (this 
is more reliable than looking at bisection logs - i tried 4 different 
bisection runs and not all were reliable.)

	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/