Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753055AbbBXKoo (ORCPT ); Tue, 24 Feb 2015 05:44:44 -0500 Received: from pandora.arm.linux.org.uk ([78.32.30.218]:59986 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751580AbbBXKom (ORCPT ); Tue, 24 Feb 2015 05:44:42 -0500 Date: Tue, 24 Feb 2015 10:43:40 +0000 From: Russell King - ARM Linux To: Arjan van de Ven Cc: Ingo Molnar , Anton Blanchard , Andrew Morton , Steven Rostedt , Michael Ellerman , Paul Mackerras , Benjamin Herrenschmidt , sam.bobroff@au1.ibm.com, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Peter Zijlstra , Don Zickus , linux-arm-kernel@lists.infradead.org, LKML , ppc-dev , X86 ML , Linus Torvalds , Arjan van de Ven Subject: Re: [PATCH 0/7] Serialise oopses, BUGs, WARNs, dump_stack, soft lockups and hard lockups Message-ID: <20150224104339.GT8656@n2100.arm.linux.org.uk> References: <1424748634-9153-1-git-send-email-anton@samba.org> <20150224063513.GA15387@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1396 Lines: 27 On Tue, Feb 24, 2015 at 01:39:46AM -0800, Arjan van de Ven wrote: > one of the question is if you want to serialize, or if you just want > to label. If you take a cookie (could just be a monotonic increasing > number) at the start of the oops and then prefix/postfix the stack > printing with that number, you don't serialize (risk of locking up), > but you can pretty trivially see which line came from where.. > if you do the monotonic increasing number approach, you even get an > ordering out of it. it does mean changing the dump_stack() and co > function fingerprint to take an extra argument, but that is not TOO > insane. I like that idea, but it relies on ensuring that each line is printed by one printk() statement - which in itself is a good idea. I'd actually like a version of print_hex_dump() which we could use for stack and code dumping - the existing print_hex_dump() assumes that it's fine to dereference the pointer, whereas for stack and code dumping, we can't always make that assumption. That's a separate issue though. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/