linux-kernel - Re: Linux 2.6.21-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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 21 Feb 2007 13:23:30 -0800
From:	Daniel Walker <dwalker@...sta.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	tglx@...utronix.de,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	mingo@...e.hu
Subject: Re: Linux 2.6.21-rc1

On Wed, 2007-02-21 at 13:06 -0800, Linus Torvalds wrote:
> 
> On Wed, 21 Feb 2007, Daniel Walker wrote:
> > 
> > Here's the final commit from the bisect which caused it . It says "No
> > changes to existing functionality" ?
> 
> Ok, it wouldn't be the first time some change that is supposed to change 
> nothing does actually change something.

Yeah , maybe I screwed something up. First time I've done a git bisect.

> That said, one thing to worry about when doing bisection: the kernel 
> configuration.
> 
> If you always just do "make oldconfig" or something, the kernel config for 
> the thing you test will depend on the _previous_ kernel you compiled, and 
> that is not always what you want. I've once had a failing kernel, did 
> bisection, and it turned out that since I had gone back in time to before 
> the option that caused the failure even existed, I had (by mistake) then 
> compiled some of the later kernels without that option enabled, and called 
> them "good". 

In this case I don't think anything was specifically turned on, beyond
SMP. For instance HRT/dynamic tick was off.

I didn't run "make oldconfig", but just running "make" asked for options
that just got added, which was nice.

> The end result: "git bisect" didn't actually end up pointing to the right 
> commit, just because I had effectively lied to it.
> 
> That said, considering that you did get a commit that doesn't look 
> entirely unlikely (and that clearly changes things that are relevant), I 
> suspect you did actually find the right one.

I think if it's not that exact commit it's still one in that set. I
mainly wanted to confirm that it was an hrt/dynamic tick issue , and not
some left field patches..

Daniel

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