From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753899AbcKYM0a (ORCPT ); Fri, 25 Nov 2016 07:26:30 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:35854 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753656AbcKYM0S (ORCPT ); Fri, 25 Nov 2016 07:26:18 -0500 Date: Fri, 25 Nov 2016 15:26:04 +0300 From: "Kirill A. Shutemov" To: Josh Poimboeuf Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Linus Torvalds , Sasha Levin , Konstantin Khlebnikov Subject: Re: [PATCH 2/4] x86/dumpstack: remove kernel text addresses from stack dump Message-ID: <20161125122604.GB3439@node.shutemov.name> References: <69329cb29b8f324bb5fcea14d61d224807fb6488.1477405374.git.jpoimboe@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69329cb29b8f324bb5fcea14d61d224807fb6488.1477405374.git.jpoimboe@redhat.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 25, 2016 at 09:51:12AM -0500, Josh Poimboeuf wrote: > Printing kernel text addresses in stack dumps is of questionable value, > especially now that address randomization is becoming common. > > It can be a security issue because it leaks kernel addresses. It also > affects the usefulness of the stack dump. Linus says: > > "I actually spend time cleaning up commit messages in logs, because > useless data that isn't actually information (random hex numbers) is > actively detrimental. > > It makes commit logs less legible. > > It also makes it harder to parse dumps. > > It's not useful. That makes it actively bad. > > I probably look at more oops reports than most people. I have not > found the hex numbers useful for the last five years, because they are > just randomized crap. > > The stack content thing just makes code scroll off the screen etc, for > example." > > The only real downside to removing these addresses is that they can be > used to disambiguate duplicate symbol names. However such cases are > rare, and the context of the stack dump should be enough to be able to > figure it out. > > There's now a 'faddr2line' script which can be used to convert a > function address to a file name and line: > > $ ./scripts/faddr2line ~/k/vmlinux write_sysrq_trigger+0x51/0x60 > write_sysrq_trigger+0x51/0x60: > write_sysrq_trigger at drivers/tty/sysrq.c:1098 > > Or gdb can be used: > > $ echo "list *write_sysrq_trigger+0x51" |gdb ~/k/vmlinux |grep "is in" > (gdb) 0xffffffff815b5d83 is in driver_probe_device (/home/jpoimboe/git/linux/drivers/base/dd.c:378). > > (But note that when there are duplicate symbol names, gdb will only show > the first symbol it finds. faddr2line is recommended over gdb because > it handles duplicates and it also does function size checking.) The commit breaks scripts/decode_stacktrace.sh. Not sure if it's possible to fix it only on decode_stacktrace.sh side: we seems don't have a way to clearly distinguish stack trace line of any other. May be we should mark stack lines with some prefix to simplify decoding? -- Kirill A. Shutemov