Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030320AbcDLP5B (ORCPT ); Tue, 12 Apr 2016 11:57:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33371 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964998AbcDLP5A (ORCPT ); Tue, 12 Apr 2016 11:57:00 -0400 Date: Tue, 12 Apr 2016 10:56:58 -0500 From: Josh Poimboeuf To: Jiri Slaby Cc: Miroslav Benes , Jiri Kosina , Jessica Yu , linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Vojtech Pavlik Subject: Re: [RFC PATCH v1.9 07/14] x86/stacktrace: add function for detecting reliable stack traces Message-ID: <20160412155658.uuz5jbtnmw3teaey@treble> References: <1f8c648ed8b8eb49a75f5a6cacf8b7ca76f44fa9.1458933243.git.jpoimboe@redhat.com> <20160404175437.gjj2ghphzv5foh4j@treble.redhat.com> <570BB1AE.6090502@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <570BB1AE.6090502@suse.cz> User-Agent: Mutt/1.6.0.1 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2189 Lines: 47 On Mon, Apr 11, 2016 at 04:16:14PM +0200, Jiri Slaby wrote: > On 04/04/2016, 07:54 PM, Josh Poimboeuf wrote: > > On Thu, Mar 31, 2016 at 03:03:16PM +0200, Miroslav Benes wrote: > >> On Fri, 25 Mar 2016, Josh Poimboeuf wrote: > >> > >>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > >>> index 2dc18605..76274b8 100644 > >>> --- a/arch/x86/Kconfig > >>> +++ b/arch/x86/Kconfig > >>> @@ -138,6 +138,7 @@ config X86 > >>> select HAVE_PERF_REGS > >>> select HAVE_PERF_USER_STACK_DUMP > >>> select HAVE_REGS_AND_STACK_ACCESS_API > >>> + select HAVE_RELIABLE_STACKTRACE if X86_64 && FRAME_POINTER > >> > >> I understand we have to rely on frame pointer for now. Do you plan to > >> switch to dwarf unwinder one day in the future? IOW is there a plan to > >> implement dwarf stuff generation in objtool and then to have a dwarf-based > >> stack unwinder upstream and to use it for live patching? > > > > Yes, adding DWARF validation and generation to objtool and creating a > > DWARF unwinder upstream are all planned, hopefully soon. > > I may seem to be obtrusive, but here, I would like to offer my help > again. If you need any kind of help with the unwinder, I can definitely > help with that. Be it coding, testing, ideas discussion or anything else. > > We had been using unwinder for over a decade in SUSE but it stopped > working for assembly recently (for obvious reasons). So having a working > and reliable unwinder again is one of the top priorities for us. Since you already have an unwinder in SUSE, it sounds like what you need most urgently is DWARF generation support in objtool so that your unwinder will work again for asm code, right? The kernel already emits DWARF today (for C code), so an upstream unwinder isn't needed first. That's high on my TODO list, and the coding is probably 70-80% done. I don't want to hold up progress... But I don't really feel comfortable passing the code off because it's quite a big feature with some major changes to objtool. Being the objtool author, I want to make sure to give it my full attention. I'm spread quite thin at the moment but I do hope to have v1 of those patches soon, hopefully May-ish. -- Josh