linux-kernel - Re: frequent lockups in 3.18rc4

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, 3 Dec 2014 07:22:44 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Chris Rorvick <chris@...vick.com>
Cc:	Dâniel Fraga <fragabr@...il.com>,
	Tejun Heo <tj@...nel.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: frequent lockups in 3.18rc4

On Tue, Dec 2, 2014 at 10:02 PM, Chris Rorvick <chris@...vick.com> wrote:
>
>> while a "good" _before_ a subsequent bad is
>> also trustworthy (because if the "good" kernel contained the bug and
>> you should have marked it bad, we'd then go on to test all the commits
>> that were *not* the bug, so we'd never see a "bad" kernel again).
>
> wouldn't marking a bad commit "good" cause you to not see a *good*
> kernel again?  Marking it "good" would seem push the search away from
> the bug toward the current "bad" commit.

Yes, you're right.

The "long series of 'good'" at the end actually implies that the last
'bad' is questionable - just marking a bad kernel as being good should
push us further into 'bad' land, not the other way around. While
marking a 'good' kernel as 'bad' will push us into 'bug hasn't
happaned yet' land.

Which is somewhat odd, because the bad kernels should be easy to spot.
But it could happen if screwing up the test (by not booting the right
kernel, for example.

Or - and this is the scary part, and one of the huge downsides of 'git
bisect' - it just ends up meaning that the bug comes and goes and is
not quite repeatable enough.

Anyway, Dâniel, if you restart the bisection today, start it one
kernel earlier: re-test the last 'bad' kernel too. So start with
reconfirming that the c9b88e958182 kernel was bad (that *might* be as
easy as just checking your old kernel boot logs, and verifying that
"yes, I really booted it, and yes, it clearly hung and I had to
hard-reboot into it")

                   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/