linux-kernel - Re: 2.6.29-rc8: Reported regressions from 2.6.28

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.2.00.0903161250080.3082@localhost.localdomain>
Date:	Mon, 16 Mar 2009 12:57:18 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jeff Chua <jeff.chua.linux@...il.com>
cc:	Ingo Molnar <mingo@...e.hu>,
	Johannes Berg <johannes@...solutions.net>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Adrian Bunk <bunk@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	Network Development <netdev@...r.kernel.org>,
	"John W. Linville" <linville@...driver.com>
Subject: Re: 2.6.29-rc8: Reported regressions from 2.6.28

On Mon, 16 Mar 2009, Jeff Chua wrote:
> 
> Take the attached bisect log and replay it

Taking a bisect log is repeatable, but pointless.

If you made any mistakes in bisecting (marking a kernel that was good as 
being bad, or the other way around), the log will always replay to the 
same thing, but it will still be wrong.

In other words, "git bisect" is only as reliable as the data you feed it, 
and if the behavior isn't 100% repeatable and unambiguous (or if you 
simply made a mistake), you need to double-check things.

So after bisecting a commit, if there is any question what-so-ever whether 
the commit makes sense as a result, you need to double-check it. The best 
way to double-check it is to go back to a known-bad state (preferably the 
tip of the branch) and revert the presumed-bad commit, and verify that it 
really fixes the behavior.

But if that is impossible (for example, because the commit no longer 
reverts cleanly), at least make 100% sure that the state at the commit is 
bad, and then go to (all) parents of that commit and make 100% sure that 
the state at those points is _good_. 

IOW, if you've pinpointed 71c11fb57b924c160297ccd9e1761db598d00ac2 as 
being bad, then you should go back and double-check that its parent 
(in this case 4607816f608b42a5379aca97ceed08378804c99f) is good.

Because if it's parent is also bad, then that just means that you made 
some mistake in "git bisect".

The thing about bisecting is that it is _extremely_ efficient. It takes 
essentially the minimal number of answers to get to the end result. But 
that very efficiency also means that getting even just _one_ of those 
answers wrong will take you _way_ off base. There's no room for error, 
because bisect will take each bit and use it to maximally split the error 
space.

In this case, it really sounds like maybe you marked the parent good, even 
though you should have marked it bad.

			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/