linux-kernel - Re: [PATCH 0/7] Serialise oopses, BUGs, WARNs, dump

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:	Tue, 24 Feb 2015 07:35:14 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Anton Blanchard <anton@...ba.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Michael Ellerman <mpe@...erman.id.au>,
	Paul Mackerras <paulus@...ba.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	sam.bobroff@....ibm.com, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, hpa@...or.com,
	Russell King <linux@....linux.org.uk>, peterz@...radead.org,
	Don Zickus <dzickus@...hat.com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linuxppc-dev@...ts.ozlabs.org, x86@...nel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH 0/7] Serialise oopses, BUGs, WARNs, dump_stack, soft
 lockups and hard lockups


* Anton Blanchard <anton@...ba.org> wrote:

> Every now and then I end up with an undebuggable issue 
> because multiple CPUs hit something at the same time and 
> everything is interleaved:
> 
>         CR: 48000082  XER: 00000000
>         ,RI
>         c0000003dc72fd10
>         ,LE
>         d0000000065b84e8
>         Instruction dump:
>         MSR: 8000000100029033
> 
> Very annoying.
> 
> Some architectures already have their own recursive 
> locking for oopses and we have another version for 
> serialising dump_stack.
> 
> Create a common version and use it everywhere (oopses, 
> BUGs, WARNs, dump_stack, soft lockups and hard lockups). 

Dunno. I've had cases where the simultaneity of the oopses 
(i.e. their garbled nature) gave me the clue about the type 
of race to expect.

To still get that information: instead of taking a 
serializing spinlock (or in addition to it), it would be 
nice to at least preserve the true time order of the 
incidents, at minimum by generating a global count for 
oopses/warnings (a bit like the oops count # currently), 
and to gather it first - before taking any spinlocks.

Thanks,

	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/