This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Mon Apr 29 00:56:26 2024 Envelope-to: j@jasper.es Delivery-date: Wed, 07 May 2014 19:31:34 +0200 Received: from localhost ([127.0.0.1] helo=squeeze.vs19.net) by squeeze.vs19.net with esmtp (Exim 4.80) (envelope-from ) id 1Wi5gs-0002yq-6Z for j@jasper.es; Wed, 07 May 2014 19:31:34 +0200 Original-Recipient: rfc822;jasper@telfort.nl Received: from pop3.telfort.nl [213.75.3.52] by squeeze.vs19.net with POP3 (fetchmail-6.3.21) for (single-drop); Wed, 07 May 2014 19:31:34 +0200 (CEST) Received: from cpxmta-msg09.kpnxchange.com (10.94.114.30) by cpxmbs-msg01.support.local (8.6.060.31) id 53696C71000AA4BC for jasper@telfort.nl; Wed, 7 May 2014 19:18:40 +0200 Received: from cpsmtpb-ews01.kpnxchange.com (213.75.39.4) by cpxmta-msg09.kpnxchange.com (8.6.060.14) id 536990B7001B630B for jasper@telfort.nl; Wed, 7 May 2014 19:18:40 +0200 Received: from cpsps-ews10.kpnxchange.com ([10.94.84.177]) by cpsmtpb-ews01.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 7 May 2014 19:18:40 +0200 Received: from vger.kernel.org ([209.132.180.67]) by cpsps-ews10.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 7 May 2014 19:18:40 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751071AbaEGRS3 (ORCPT ); Wed, 7 May 2014 13:18:29 -0400 Received: from mail-ee0-f50.google.com ([74.125.83.50]:35530 "EHLO mail-ee0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750702AbaEGRS1 convert rfc822-to-8bit (ORCPT ); Wed, 7 May 2014 13:18:27 -0 Received: by mail-ee0-f50.google.com with SMTP id e51so989743eek.9 for ; Wed, 07 May 2014 10:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; b X-Received: by 10.15.98.68 with SMTP id bi44mr16958569eeb.97.1399483106042; Wed, 07 May 2014 10:18:26 -0700 (PDT) Received: from gmail.com (54033583.catv.pool.telekom.hu. [84.3.53.131]) by mx.google.com with ESMTPSA id 48sm47647219eei.24.2014.05.07.10.18.23 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 07 Date: Wed, 7 May 2014 19:18:22 +0200 From: Ingo Molnar To: Linus Torvalds Cc: Richard Yao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , the arch/x86 maintainers , Andrew Morton , Tejun Heo , Vineet Subject: Re: [PATCH] x86/dumpstack: Walk frames when built with frame pointers Message-Id: <20140507171821.GA16671@gmail.com> References: <1398535818-14217-1-git-send-email-ryao@gentoo.org> <20140427120820.GC22116@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-Id: X-Mailing-List: linux-kernel@vger.kernel.org X-OriginalArrivalTime: 07 May 2014 17:18:40.0751 (UTC) FILETIME=[640F2FF0:01CF6A18] X-RcptDomain: telfort.nl * Linus Torvalds wrote: > So to take your example, it might be something like this > > arch_trigger_all_cpu_backtrace+0x3c -> do_raw_spin_lock+0xb7 > -> _raw_spin_lock_irqsave+0x35 -> ? prepare_to_wait+0x18 > -> prepare_to_wait+0x18 -> ? generic_make_request+0x80 > -> ? unmap_underlying_metadata+0x2e -> __wait_on_bit+0x20 > -> ? submit_bio+0xd2 -> out_of_line_wait_on_bit+0x54 > -> ? unmap_underlying_metadata+0x2e -> ? autoremove_wake_function+0x31 > -> __wait_on_buffer+0x1b -> __ext3_get_inode_loc+0x1ef -> ext3_iget+0x45 > -> ext3_lookup+0x97 -> lookup_real+0x20 -> __lookup_hash+0x2a > -> lookup_slow+0x36 -> path_lookupat+0xf9 -> filename_lookup+0x1f > -> user_path_at_empty+0x3f -> user_path_at+0xd -> vfs_fstatat+0x40 > -> ? lg_local_unlock+0x31 -> vfs_stat+0x13 -> sys_stat64+0x11 > -> ? __fput+0x187 -> ? restore_all+0xf -> ? trace_hardirqs_on_thunk+0xc > -> syscall_call+0x7 > > which is admittedly complete line noise, but is just 13 lines rather > than 31. That can sometimes be a really big deal. Let me try to offer a few more mockups with different typographical variants: 1) 'intelligently skip offsets': arch_trigger_all_cpu_backtrace -> do_raw_spin_lock -> _raw_spin_lock_irqsave -> ? prepare_to_wait -> prepare_to_wait -> ? generic_make_request -> ? unmap_underlying_metadata -> __wait_on_bit -> ? submit_bio+0xd2 -> out_of_line_wait_on_bit -> ? unmap_underlying_metadata -> ? autoremove_wake_function -> __wait_on_buffer -> __ext3_get_inode_loc -> ext3_iget -> ext3_lookup -> lookup_real -> __lookup_hash -> lookup_slow -> path_lookupat -> filename_lookup -> user_path_at_empty -> user_path_at -> vfs_fstatat -> ? lg_local_unlock -> vfs_stat -> sys_stat64 -> ? __fput -> ? restore_all -> ? trace_hardirqs_on_thunk -> syscall_call+0x7 Note how the offset is skipped intelligently, by adding an attribute to kallsyms entries: the number of callouts in that function. For functions that only have a single call, no offset information is needed. For functions that have multiple call instructions, the offset is printed - such as the 'submit_bio+0xd2' case shows it in the mockup above. 2) +'vertically aligned, screen split in two' arch_trigger_all_cpu_backtrace -> do_raw_spin_lock -> _raw_spin_lock_irqsave -> ? prepare_to_wait -> prepare_to_wait -> ? generic_make_request -> ? unmap_underlying_metadata -> __wait_on_bit -> ? submit_bio+0xd2 -> out_of_line_wait_on_bit -> ? unmap_underlying_metadata -> ? autoremove_wake_function -> __wait_on_buffer -> __ext3_get_inode_loc -> ext3_iget -> ext3_lookup -> lookup_real -> __lookup_hash -> lookup_slow -> path_lookupat -> filename_lookup -> user_path_at_empty -> user_path_at -> vfs_fstatat -> ? lg_local_unlock -> vfs_stat -> sys_stat64 -> ? __fput -> ? restore_all -> ? trace_hardirqs_on_thunk -> syscall_call This is pretty readable, and if you only look at the left side column, it still gives a shortened 'pattern' that gives an impression as to what rough call context this is. The first and last entry would always be printed on the left hand side, to make the 'left column' unconditionally readable. This mockup fits on 80col screens. 3) +'function parentheses' arch_trigger_all_cpu_backtrace() -> do_raw_spin_lock() -> _raw_spin_lock_irqsave() -> ? prepare_to_wait -> prepare_to_wait() -> ? generic_make_request -> ? unmap_underlying_metadata -> __wait_on_bit() -> ? submit_bio+0xd2 -> out_of_line_wait_on_bit() -> ? unmap_underlying_metadata -> ? autoremove_wake_function -> __wait_on_buffer() -> __ext3_get_inode_loc() -> ext3_iget() -> ext3_lookup() -> lookup_real() -> __lookup_hash() -> lookup_slow() -> path_lookupat() -> filename_lookup() -> user_path_at_empty() -> user_path_at() -> vfs_fstatat() -> ? lg_local_unlock -> vfs_stat() -> sys_stat64() -> ? __fput -> ? restore_all -> ? trace_hardirqs_on_thunk -> syscall_call()+0x7 This is more readable to me personally, as it's more C-alike. Note how only 'real' FP entries without question marks get the parentheses. This gives more visual separation between 'real' and 'noise' entries. 4) +'square brackets for unknown entries' arch_trigger_all_cpu_backtrace() -> do_raw_spin_lock() -> _raw_spin_lock_irqsave() -> ? [prepare_to_wait] -> prepare_to_wait() -> ? [generic_make_request] -> ? [unmap_underlying_metadata] -> __wait_on_bit() -> ? [submit_bio+0xd2] -> out_of_line_wait_on_bit() -> ? [unmap_underlying_metadata] -> ? [autoremove_wake_function] -> __wait_on_buffer() -> __ext3_get_inode_loc() -> ext3_iget() -> ext3_lookup() -> lookup_real() -> __lookup_hash() -> lookup_slow() -> path_lookupat() -> filename_lookup() -> user_path_at_empty() -> user_path_at() -> vfs_fstatat() -> ? [lg_local_unlock] -> vfs_stat() -> sys_stat64() -> ? [__fput] -> ? [restore_all] -> ? [trace_hardirqs_on_thunk] -> syscall_call()+0x7 To my eyes this further de-emphasises 'unknown' entries that are uninteresting noise in most cases. Makes it a bit more easy for me to ignore them. YMMV: the brackets might increase emphasis for you ... 5) #3+'vertically aligned, screen split in three' arch_trigger_all_cpu_backtrace() -> do_raw_spin_lock() -> _raw_spin_lock_irqsave() -> ? prepare_to_wait() -> prepare_to_wait() -> ? generic_make_request() -> ? unmap_underlying_metadata() -> __wait_on_bit() -> ? submit_bio()+0xd2 -> out_of_line_wait_on_bit() -> ? unmap_underlying_metadata() -> ? autoremove_wake_function() -> __wait_on_buffer() -> __ext3_get_inode_loc() -> ext3_iget() -> ext3_lookup() -> lookup_real() -> __lookup_hash() -> lookup_slow() -> path_lookupat() -> filename_lookup() -> user_path_at_empty() -> user_path_at() -> vfs_fstatat() -> ? lg_local_unlock() -> vfs_stat() -> sys_stat64() -> ? __fput() -> ? restore_all() -> ? trace_hardirqs_on_thunk() -> syscall_call()+0x7 Still mostly readable, but more compressed, 11 lines only. Width is 110+ chars though, so does not fit on col80 screens easily. This might be overdoing the horizontal compression, for little gain. 6) color tricks to de-emphasise unknown entries. On color consoles I'd also print unknown entries in grey, to make it easier to interpret screenshots and 'dmesg' output. (The color codes might not make it into the syslog, but that's OK.) I'd also print the symbolic resolution of the crash RIP in red. Here's a mockup, I'm using ASCII color codes, so this might not render in color on all mail readers: RIP: 0010:[] []generic_exec_single+0x52/0x70 ===================== Conclusion: So to me #4 looks best, and it's 16 lines instead of 31. Not as compact as your mockup that has 13 lines, but pretty close. (I'd also do the color tricks on #6, but that's more technically challenging and I also don't look forward fighting the syslog guys over it...) I'd guess that some people would prefer #2 or #3, depending on how ergonomic the parentheses and brackets are for them. Thanks, Ingo -- 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/