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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
