On 12/01/2016, 09:59 PM, Josh Poimboeuf wrote:
> I honestly am planning on picking it back up as soon as I post the
> consistency model v3, probably next week.
>
> Here's its current state, though it ain't pretty:
>
> https://github.com/jpoimboe/linux/tree/objtool-dwarf
FWIW, I had to port
On 12/01/2016, 09:59 PM, Josh Poimboeuf wrote:
> I honestly am planning on picking it back up as soon as I post the
> consistency model v3, probably next week.
>
> Here's its current state, though it ain't pretty:
>
> https://github.com/jpoimboe/linux/tree/objtool-dwarf
FWIW, I had to port
On Thu, Dec 01, 2016 at 09:28:37PM +0100, Jiri Slaby wrote:
> On 06/13/2016, 11:58 PM, Josh Poimboeuf wrote:
> > On Thu, Jun 09, 2016 at 10:31:01AM +0200, Jiri Slaby wrote:
> >> On 04/12/2016, 05:56 PM, Josh Poimboeuf wrote:
> We had been using unwinder for over a decade in SUSE but it
On Thu, Dec 01, 2016 at 09:28:37PM +0100, Jiri Slaby wrote:
> On 06/13/2016, 11:58 PM, Josh Poimboeuf wrote:
> > On Thu, Jun 09, 2016 at 10:31:01AM +0200, Jiri Slaby wrote:
> >> On 04/12/2016, 05:56 PM, Josh Poimboeuf wrote:
> We had been using unwinder for over a decade in SUSE but it
On 06/13/2016, 11:58 PM, Josh Poimboeuf wrote:
> On Thu, Jun 09, 2016 at 10:31:01AM +0200, Jiri Slaby wrote:
>> On 04/12/2016, 05:56 PM, Josh Poimboeuf wrote:
We had been using unwinder for over a decade in SUSE but it stopped
working for assembly recently (for obvious reasons). So
On 06/13/2016, 11:58 PM, Josh Poimboeuf wrote:
> On Thu, Jun 09, 2016 at 10:31:01AM +0200, Jiri Slaby wrote:
>> On 04/12/2016, 05:56 PM, Josh Poimboeuf wrote:
We had been using unwinder for over a decade in SUSE but it stopped
working for assembly recently (for obvious reasons). So
On Thu, Jun 09, 2016 at 10:31:01AM +0200, Jiri Slaby wrote:
> On 04/12/2016, 05:56 PM, Josh Poimboeuf wrote:
> >> 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
On Thu, Jun 09, 2016 at 10:31:01AM +0200, Jiri Slaby wrote:
> On 04/12/2016, 05:56 PM, Josh Poimboeuf wrote:
> >> 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
On 04/12/2016, 05:56 PM, Josh Poimboeuf wrote:
>> 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
On 04/12/2016, 05:56 PM, Josh Poimboeuf wrote:
>> 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
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
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
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
>>> +++
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
>>> +++
On Thu 2016-04-07 09:46:55, Josh Poimboeuf wrote:
> On Thu, Apr 07, 2016 at 01:55:52PM +0200, Petr Mladek wrote:
> > Well, I wonder if we should be more suspicious and make
> > sure that only the regular process stack is used.
>
> Notice the save_stack_stack_reliable() function, which is called
On Thu 2016-04-07 09:46:55, Josh Poimboeuf wrote:
> On Thu, Apr 07, 2016 at 01:55:52PM +0200, Petr Mladek wrote:
> > Well, I wonder if we should be more suspicious and make
> > sure that only the regular process stack is used.
>
> Notice the save_stack_stack_reliable() function, which is called
On Thu, Apr 07, 2016 at 01:55:52PM +0200, Petr Mladek wrote:
> On Fri 2016-03-25 14:34:54, Josh Poimboeuf wrote:
> > For live patching and possibly other use cases, a stack trace is only
> > useful if you can be assured that it's completely reliable. Add a new
> > save_stack_trace_tsk_reliable()
On Thu, Apr 07, 2016 at 01:55:52PM +0200, Petr Mladek wrote:
> On Fri 2016-03-25 14:34:54, Josh Poimboeuf wrote:
> > For live patching and possibly other use cases, a stack trace is only
> > useful if you can be assured that it's completely reliable. Add a new
> > save_stack_trace_tsk_reliable()
On Fri 2016-03-25 14:34:54, Josh Poimboeuf wrote:
> For live patching and possibly other use cases, a stack trace is only
> useful if you can be assured that it's completely reliable. Add a new
> save_stack_trace_tsk_reliable() function to achieve that.
>
> Scenarios which indicate that a stack
On Fri 2016-03-25 14:34:54, Josh Poimboeuf wrote:
> For live patching and possibly other use cases, a stack trace is only
> useful if you can be assured that it's completely reliable. Add a new
> save_stack_trace_tsk_reliable() function to achieve that.
>
> Scenarios which indicate that a stack
On Mon, Apr 04, 2016 at 05:55:01PM +0200, Petr Mladek wrote:
> On Fri 2016-03-25 14:34:54, Josh Poimboeuf wrote:
> > For live patching and possibly other use cases, a stack trace is only
> > useful if you can be assured that it's completely reliable. Add a new
> > save_stack_trace_tsk_reliable()
On Mon, Apr 04, 2016 at 05:55:01PM +0200, Petr Mladek wrote:
> On Fri 2016-03-25 14:34:54, Josh Poimboeuf wrote:
> > For live patching and possibly other use cases, a stack trace is only
> > useful if you can be assured that it's completely reliable. Add a new
> > save_stack_trace_tsk_reliable()
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
> >
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
> >
On Fri 2016-03-25 14:34:54, Josh Poimboeuf wrote:
> For live patching and possibly other use cases, a stack trace is only
> useful if you can be assured that it's completely reliable. Add a new
> save_stack_trace_tsk_reliable() function to achieve that.
>
> Scenarios which indicate that a stack
On Fri 2016-03-25 14:34:54, Josh Poimboeuf wrote:
> For live patching and possibly other use cases, a stack trace is only
> useful if you can be assured that it's completely reliable. Add a new
> save_stack_trace_tsk_reliable() function to achieve that.
>
> Scenarios which indicate that a stack
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
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
28 matches
Mail list logo
