From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752201AbbCYXfa (ORCPT ); Wed, 25 Mar 2015 19:35:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41530 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751347AbbCYXf1 (ORCPT ); Wed, 25 Mar 2015 19:35:27 -0400 Date: Wed, 25 Mar 2015 18:34:55 -0500 From: Josh Poimboeuf To: Jiri Kosina Cc: Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Michal Marek , Peter Zijlstra , x86@kernel.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/2] Compile-time stack frame pointer validation Message-ID: <20150325233455.GA15796@treble.redhat.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 26, 2015 at 12:24:45AM +0100, Jiri Kosina wrote: > On Wed, 25 Mar 2015, Josh Poimboeuf wrote: > > > In discussions around my live kernel patching consistency model RFC [1], > > Peter and Ingo correctly pointed out that stack traces aren't reliable. > > And as Ingo said, there's no "strong force" which ensures we can rely on > > them. > > > > So I've been thinking about how to fix that. My goal is to eventually > > make stack traces reliable. Or at the very least, to be able to detect > > at runtime when a given stack trace *might* be unreliable. But improved > > stack traces would broadly benefit the entire kernel, regardless of the > > outcome of the live kernel patching consistency model discussions. > [ ... snip ... ] > > I haven't really gone through your patchset thoroughly yet, but I just > wanted to make sure that you are aware of existing DWARF-based stack > unwinder which exists for the kernel. > > It's not merged in mainline (one of the reasons being disagreements about > bugfixes between Jan and Linus), but we've been carrying it in SUSE > kernels as an out-of-tree patch for quite some time, and it really makes > stack dumps much more reliable and understandable. > > You can see it for example here: > > http://kernel.suse.com/cgit/kernel-source/tree/patches.suse/stack-unwind > > (and some merge attempt failures due to disagreements between Jan and > Linus, not really completely related to the actual code itself, in LKML > archives). Thanks, that could be helpful. I also found a nice (currently only 32-bit) DWARF unwinder in arch/sh/kernel/dwarf.c. The DWARF metadata has a reputation for being unreliable, but I have some ideas on how to improve it for future patch sets, with both compile-time and runtime validations. -- Josh