Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1370805 > unrolled thread

Re: [RFC PATCH v1.9 07/14] x86/stacktrace: add function for detecting reliable stack traces

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC PATCH v1.9 07/14] x86/stacktrace: add function for  detecting reliable stack traces Josh Poimboeuf <jpoimboe@redhat.com> - 2016-04-04 20:00 +0200
    Re: [RFC PATCH v1.9 07/14] x86/stacktrace: add function for detecting  reliable stack traces Jiri Slaby <jslaby@suse.cz> - 2016-04-11 16:20 +0200
      Re: [RFC PATCH v1.9 07/14] x86/stacktrace: add function for  detecting reliable stack traces Josh Poimboeuf <jpoimboe@redhat.com> - 2016-04-12 18:00 +0200

#1370805 — Re: [RFC PATCH v1.9 07/14] x86/stacktrace: add function for detecting reliable stack traces

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.

> We have FRAME_POINTER unset in SLES for performance reasons (there was 
> some 5 percent slowdown measured in the past. However we should redo the 
> experiments.) and one day we'd really like to switch to upstream from 
> kgraft :). So I'm just asking.

If you redo the experiments and have some useful data to share, please
do share :-)

-- 
Josh

[toc] | [next] | [standalone]

#1376009 — Re: [RFC PATCH v1.9 07/14] x86/stacktrace: add function for detecting reliable stack traces

[Multipart message — attachments visible in raw view] — view raw

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.

thanks,
-- 
js
suse labs

[toc] | [prev] | [next] | [standalone]

#1376974

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web