linux-kernel - Re: [ARM] Regression somewhere between 2.6.19 and 2.6.19-rc1

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] [day] [month] [year] [list]

Date:	Tue, 2 Jan 2007 08:57:07 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	Russell King <rmk+lkml@....linux.org.uk>
cc:	Linux Kernel List <linux-kernel@...r.kernel.org>
Subject: Re: [ARM] Regression somewhere between 2.6.19 and 2.6.19-rc1

On Tue, 2 Jan 2007, Russell King wrote:
>
> How do I tell git bisect "I can't test this, this is neither good nor bad,
> please choose another to try" ?  Or is git bisect hopeless given the large
> amount of unbuildable commits thanks to our weekly merges?

The easiest way to do this is to start off with

	git bisect visualize

which will just show you all the potentially interesting commits, and you 
can just browse it for commits that you deem to be (a) ok to try and (b) 
hopefully _somewhat_ central to bisection (ie if you pick something that 
is very close to one of the already-checked points, the efficiency of 
bisection drops a lot - it will still _work_, but if it's not "near the 
middle of the pack" it simply won't be very efficient any more.

And then just do

	git reset --hard <hand-picked-point>

and off you go. Compile, test, and do "git bisect bad/good" (at which 
point "git bisect" will again pick a half-way point automatically for you, 
but hopefully you'll have gotten out of the problematic region so you 
don't need to override it by hand any more. But you _can_ always override 
it, of course).

You can also use the "git reset --hard xyzzy" overrides in case you have a 
suspicion about where things happen, and you want to narrow things down by 
hand by testing a point closer to the suspicious area. Usually the 
bisection is very efficient, but if you have a good clue where the problem 
happens, pointing in the right direction and trying to force bisection to 
look at a special place will obviously help further.

Of course, if your "good clue" was actually garbage, you'll just make 
bisection take longer instead ;)

		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/