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:	Fri, 2 Mar 2007 09:04:41 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jens Axboe <jens.axboe@...cle.com>, Pavel Machek <pavel@....cz>,
	Adrian Bunk <bunk@...sta.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"Michael S. Tsirkin" <mst@...lanox.co.il>,
	Thomas Gleixner <tglx@...utronix.de>, linux-pm@...ts.osdl.org,
	Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
	Daniel Walker <dwalker@...sta.com>,
	Len Brown <lenb@...nel.org>, git@...r.kernel.org
Subject: Re: 2.6.21-rc1: known regressions (part 2)


* Ingo Molnar <mingo@...e.hu> wrote:

> I'll try what i've described in the previous mail: mark all bisection 
> points that do not include f3ccb06f as 'good' - thus 'merging' the 
> known-bad area with the first known-good commit, and thus eliminating 
> it from the bisection space.

this got me quite a bit further:

 git-bisect start
 git-bisect bad       01363220f5d23ef68276db8974e46a502e43d01d
 git-bisect good      f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 
 git-bisect fake-good ee404566f97f9254433399fbbcfa05390c7c55f7
 git-bisect bad       d43a338e395371733a80ec473b40baac5f74d768
 git-bisect bad       255f0385c8e0d6b9005c0e09fffb5bd852f3b506
 git-bisect fake-good f99c6bb6e2e9c35bd3dc0b1d0faa28bd6970930d
 git-bisect fake-good 0187f221e96e3436d552c0c7143f183eb82fb658
 git-bisect bad       81450b73dde07f473a4a7208b209b4c8b7251d90
 git-bisect fake-good ef29498655b18d2bfd69048e20835d19333981ab
 git-bisect fake-good 8a03d9a498eaf02c8a118752050a5154852c13bf
 git-bisect good      5c95d3f5783ab184f64b7848f0a871352c35c3cf
 git-bisect good      ecb5f7521a309cb9c5fc0832b9705cd2a03d7d45
 git-bisect good      0539771d7236b425f285652f6f297cc7939c8f9a

 81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit

[ note: by having the "git-bisect must-have-bugfix f3ccb06f" 
  functionality i mentioned in the previous mail git-bisect could
  have eliminated the fake-good steps. ]

it's not a resolution of this regression yet, because this commit is a 
merge with upstream:

|  commit 81450b73dde07f473a4a7208b209b4c8b7251d90
|  Merge: 8a03d9a... 0539771...
|  Author: Len Brown <len.brown@...el.com>
|  Date:   Fri Feb 16 18:52:41 2007 -0500
|
|      Pull misc-for-upstream into release branch

which means that the fix in Len's tree got broken by merging with 
upstream. Note: this 'upstream' in isolation is broken too, due to not 
having that essential fix from Len's tree!

So we quite likely have /two/ bugs, any of which breaks resume (which 
breakage looks the same, so no way to isolate them via testing).

I'll now try the following: i'll try to manually apply Len's fix to 
every tree that git-bisect offers me, in the hope of being able to 
isolate the /other/ bug.

[ But really, i'm not expecting any miracles because this is way out of
  league for git-bisect which really depends on only having a binary 
  space to search for. ]

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ