linux-kernel - Re: 2.6.22-rc5 regression

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: <alpine.LFD.0.98.0706191649160.3593@woody.linux-foundation.org>
Date:	Tue, 19 Jun 2007 17:09:10 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Carlo Wood <carlo@...noe.com>
cc:	Dave Jones <davej@...hat.com>, linux-kernel@...r.kernel.org,
	eric@...olt.net, zhenyu.z.wang@...el.com, lethal@...ux-sh.org,
	y-goto@...fujitsu.com
Subject: Re: 2.6.22-rc5 regression

On Wed, 20 Jun 2007, Carlo Wood wrote:

> On Mon, Jun 18, 2007 at 03:57:51PM -0700, Linus Torvalds wrote:
> > > I'll redo the bisect with this new git.
> > 
> > Thanks,
> > 		Linus
> 
> Well, I did a new 'git bisect' - and if you ask me - it is still broken.
> 
> It's conclusion was this time:
> 
> hikaru:/usr/src/kernel/git/linux-2.6>git bisect bad
> 01da41b86f6e5f9a724e20a63f093d77e37d8056 is first bad commit
> 
>     parisc: make command_line[] static

Heh.

Yeah, at this point I think we can pretty much guarantee that your problem 
is one of two cases:

 - either a bit random, and depends on some timing thing, and one of the 
   kernels you marked "good" wasn't really.

   It's not likely that you marked a good kernel bad, of course, since 
   with a good kernel, everything should have always worked, but with a 
   bad kernel and a bug that isn't entirely reproducible, you'd mark it 
   "good" by mistake - because it just randomly didn't show the problem.

OR

 - we actually have two different commits that introduce the problem for 
   you, and it comes and goes, and the bisection doesn't work, because 
   there isn't a clear "this side works, that other side does not" 
   situation.

For example, later on you say:

> Personally I am convinced that the real problem is with
> 8888985144db8f4cb7e56154b31bdf233d3550bf

but if you look at your commit log, you have:

> # bad: [25971f68d392f1816e21520e9e59648403b0bdad] [PARISC] fix section
> # mismatch in ccio-dma
> git-bisect bad 25971f68d392f1816e21520e9e59648403b0bdad

Notice? You said that 25971f68d392f1816e21520e9e59648403b0bdad was bad, 
but that is *before_ the 8888985144db8f4cb7e56154b31bdf233d3550bf commit. 
Do a

	gitk 25971f68d3..8888985144

to see that part of the history.

So maybe you didn't test that kernel properly? And maybe it really is 
random, and something has happened that just makes it happen more often?

Also, some *really* nasty bugs end up being about bad initialization, and 
it turns out that what happens more is not which kernel you run, but what 
the *previous* kernel you ran is, because it left some device driver state 
that the bug doesn't clean up!

Anyway, can you try that 25971f68d3 kernel one more time? You marked it 
bad, but if that kernel is bad, then the commit you are pointing to is 
*not* the culprit.

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