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: <20070620131120.GA17615@alinoe.com>
Date:	Wed, 20 Jun 2007 15:11:20 +0200
From:	Carlo Wood <carlo@...noe.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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 Tue, Jun 19, 2007 at 05:09:10PM -0700, Linus Torvalds wrote:
> 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.

Nope

>    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.

Nope

> 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.

Yes

Looking a bit closer to the bisect myself, I note that 
25971f68d392f1816e21520e9e59648403b0bdad and
aba297927d1d558c7a94548135133bdf9172708a are part of
a branch that is derived from a very "old" revision.
git bisect assumes that such an old revision is good,
but in fact - that was already bad as well, because
the history of this bug is:

2.6.22-rc5 BAD
2.6.22-rc4+somethingelse BAD
2.6.22-rc4+something GOOD
2.6.22-rc4 BAD
...
2.6.18-rc1 BAD
2.6.18 GOOD

Thus: BAD BAD BAD GOOD GOOD BAD BAD

and git bisect can't handle that, even though I started
with a 'good' start point and a bad start point at the end.

> 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.

This part is thus based upon a revision so old that it was bad again,
even before the small period that it was good.

> 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?

No, it is really 100% reproducible.

-- 
Carlo Wood <carlo@...noe.com>
-
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/