linux-kernel - Re: [git pull] x86 fixes

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: <20090112220326.GB12462@elte.hu>
Date:	Mon, 12 Jan 2009 23:03:26 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Torsten Kaiser <just.for.lkml@...glemail.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [git pull] x86 fixes

* Torsten Kaiser <just.for.lkml@...glemail.com> wrote:

> On Mon, Jan 12, 2009 at 9:52 PM, Ingo Molnar <mingo@...e.hu> wrote:
> > The reason why we wanted to re-test the functional changes was that
> > Torsten's crash looks very weird: double Call Trace line, a crash in the
> > scsi/ata code, showing the after-effects of some sort of memory corruption
> > there.
> 
> The double Call Trace: line was a copy&paste error on my part. Its not
> there in the original oops.
> 
> Sorry for that...

ah, ok - that's fine.

I was just wondering whether it was two CPUs crashing at once and 
producing an overlap - or something like that. (although typically in that 
case we dont get such nice line duplication - we get totally garbled 
output of the two oopses superimposed.)

It's just that when an oops looks weird we have to look at every small 
detail, to be able to imagine the unimaginable.

Bugs you cannot even imagine are the toughest nuts usually, as the process 
of debugging narrows imagination usually - often it involves repetitive 
automatisms which are not helpful in expanding your thoughts to cover 
tricky, unusual bugs.

If an oops looks difficult there's a way out of that trap: co-debug in 
duos if you can - the same folks rarely get unimaginative for the very 
same detail. (Or put it aside and leave it for the next morning - to flush 
out the invisible temporary mental dead-ends one has installed 
subconsciously and which are blocking you from reaching the real 
solution.)

	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/