On Tue, Jun 30, 2020 at 09:04:12PM +0800, Wangshaobo (bobo) wrote:
>
> 在 2020/6/5 9:51, Josh Poimboeuf 写道:
> > On Fri, Jun 05, 2020 at 09:26:42AM +0800, Wangshaobo (bobo) wrote:
> > > > > So, I want to ask is there any side effects if i modify like this ?
> > > > > this
> > > > > modification is
在 2020/6/5 9:51, Josh Poimboeuf 写道:
On Fri, Jun 05, 2020 at 09:26:42AM +0800, Wangshaobo (bobo) wrote:
So, I want to ask is there any side effects if i modify like this ? this
modification is based on
your fix. It looks like ok with proper test.
diff --git a/arch/x86/kernel/unwind_orc.c
On Fri, Jun 05, 2020 at 09:26:42AM +0800, Wangshaobo (bobo) wrote:
> > > So, I want to ask is there any side effects if i modify like this ? this
> > > modification is based on
> > >
> > > your fix. It looks like ok with proper test.
> > >
> > > diff --git a/arch/x86/kernel/unwind_orc.c
在 2020/6/4 10:40, Josh Poimboeuf 写道:
On Thu, Jun 04, 2020 at 09:24:55AM +0800, Wangshaobo (bobo) wrote:
在 2020/6/3 23:33, Josh Poimboeuf 写道:
On Wed, Jun 03, 2020 at 10:06:07PM +0800, Wangshaobo (bobo) wrote:
To be honest, I don't remember what I meant by sibling calls. They
don't even leave
On Thu, Jun 04, 2020 at 09:24:55AM +0800, Wangshaobo (bobo) wrote:
>
> 在 2020/6/3 23:33, Josh Poimboeuf 写道:
> > On Wed, Jun 03, 2020 at 10:06:07PM +0800, Wangshaobo (bobo) wrote:
> > To be honest, I don't remember what I meant by sibling calls. They
> > don't even leave anything on the stack.
>
在 2020/6/3 23:33, Josh Poimboeuf 写道:
On Wed, Jun 03, 2020 at 10:06:07PM +0800, Wangshaobo (bobo) wrote:
To be honest, I don't remember what I meant by sibling calls. They
don't even leave anything on the stack.
For noreturns, the code might be laid out like this:
func1:
...
On Wed, Jun 03, 2020 at 10:06:07PM +0800, Wangshaobo (bobo) wrote:
> Today I test your fix, but arch_stack_walk_reliable() still return failed
> sometimes, I
>
> found one of three scenarios mentioned failed:
>
>
> 1. user task (just fork) but not been scheduled
>
> test FAILED
>
> it
在 2020/6/2 21:14, Josh Poimboeuf 写道:
On Tue, Jun 02, 2020 at 09:22:30AM +0800, Wangshaobo (bobo) wrote:
so i think this question is related to ORC unwinder, could i ask if you have
strategy or plan to avoid this problem ?
I suspect something like this would fix it (untested):
diff --git
On Tue, Jun 02, 2020 at 09:22:30AM +0800, Wangshaobo (bobo) wrote:
> so i think this question is related to ORC unwinder, could i ask if you have
> strategy or plan to avoid this problem ?
I suspect something like this would fix it (untested):
diff --git a/arch/x86/kernel/stacktrace.c
在 2020/6/2 2:05, Josh Poimboeuf 写道:
On Sat, May 30, 2020 at 10:21:19AM +0800, Wangshaobo (bobo) wrote:
1) when a user mode task just fork start excuting ret_from_fork() till
schedule_tail, unwind_next_frame found
orc->sp_reg is ORC_REG_UNDEFINED but orc->end not equals zero, this time
On Sat, May 30, 2020 at 10:21:19AM +0800, Wangshaobo (bobo) wrote:
> 1) when a user mode task just fork start excuting ret_from_fork() till
> schedule_tail, unwind_next_frame found
>
> orc->sp_reg is ORC_REG_UNDEFINED but orc->end not equals zero, this time
> arch_stack_walk_reliable()
>
>
On Fri, May 29, 2020 at 06:10:59PM +0800, Wang ShaoBo wrote:
> Stack unreliable error is reported by stack_trace_save_tsk_reliable() when
> trying
> to insmod a hot patch for module modification, this results in frequent
> failures
> sometimes. We found this 'unreliable' stack is from task just
Stack unreliable error is reported by stack_trace_save_tsk_reliable() when
trying
to insmod a hot patch for module modification, this results in frequent failures
sometimes. We found this 'unreliable' stack is from task just fork.
The task just fork need to go through these steps will the
13 matches
Mail list logo
