On Fri, Mar 26, 2021 at 10:20:09AM -0400, Steven Rostedt wrote:
> On Fri, 26 Mar 2021 21:03:49 +0900
> Masami Hiramatsu wrote:
>
> > I confirmed this is not related to this series, but occurs when I build
> > kernels with different
> > configs without cleanup.
> >
> > Once I build kernel with
On Fri, 26 Mar 2021 21:03:49 +0900
Masami Hiramatsu wrote:
> I confirmed this is not related to this series, but occurs when I build
> kernels with different
> configs without cleanup.
>
> Once I build kernel with CONFIG_UNWIND_GUESS=y (for testing), and after that,
> I build kernel again with
On Fri, 26 Mar 2021 03:05:03 +0900
Masami Hiramatsu wrote:
> On Wed, 24 Mar 2021 10:40:58 +0900
> Masami Hiramatsu wrote:
>
> > On Tue, 23 Mar 2021 23:30:07 +0100
> > Peter Zijlstra wrote:
> >
> > > On Mon, Mar 22, 2021 at 03:41:40PM +0900, Masami Hiramatsu wrote:
> > > > ".global
On Wed, 24 Mar 2021 10:40:58 +0900
Masami Hiramatsu wrote:
> On Tue, 23 Mar 2021 23:30:07 +0100
> Peter Zijlstra wrote:
>
> > On Mon, Mar 22, 2021 at 03:41:40PM +0900, Masami Hiramatsu wrote:
> > > ".global kretprobe_trampoline\n"
> > > ".type kretprobe_trampoline, @function\n"
> > >
On Mon, Mar 22, 2021 at 03:41:40PM +0900, Masami Hiramatsu wrote:
> ".global kretprobe_trampoline\n"
> ".type kretprobe_trampoline, @function\n"
> "kretprobe_trampoline:\n"
> #ifdef CONFIG_X86_64
So what happens if we get an NMI here? That is, after the RET but before
the push?
On Wed, 24 Mar 2021 20:26:13 -0400
Steven Rostedt wrote:
> On Thu, 25 Mar 2021 08:47:41 +0900
> Masami Hiramatsu wrote:
>
> > > I think the REGS and REGS_PARTIAL cases can also be affected by function
> > > graph tracing. So should they use the generic unwind_recover_ret_addr()
> > > instead
On Thu, 25 Mar 2021 08:47:41 +0900
Masami Hiramatsu wrote:
> > I think the REGS and REGS_PARTIAL cases can also be affected by function
> > graph tracing. So should they use the generic unwind_recover_ret_addr()
> > instead of unwind_recover_kretprobe()?
>
> Yes, but I'm not sure this
On Wed, 24 Mar 2021 11:01:43 -0500
Josh Poimboeuf wrote:
> On Wed, Mar 24, 2021 at 10:40:58AM +0900, Masami Hiramatsu wrote:
> > On Tue, 23 Mar 2021 23:30:07 +0100
> > Peter Zijlstra wrote:
> >
> > > On Mon, Mar 22, 2021 at 03:41:40PM +0900, Masami Hiramatsu wrote:
> > > > ".global
On Wed, Mar 24, 2021 at 10:40:58AM +0900, Masami Hiramatsu wrote:
> On Tue, 23 Mar 2021 23:30:07 +0100
> Peter Zijlstra wrote:
>
> > On Mon, Mar 22, 2021 at 03:41:40PM +0900, Masami Hiramatsu wrote:
> > > ".global kretprobe_trampoline\n"
> > > ".type kretprobe_trampoline, @function\n"
> > >
On Tue, 23 Mar 2021 23:30:07 +0100
Peter Zijlstra wrote:
> On Mon, Mar 22, 2021 at 03:41:40PM +0900, Masami Hiramatsu wrote:
> > ".global kretprobe_trampoline\n"
> > ".type kretprobe_trampoline, @function\n"
> > "kretprobe_trampoline:\n"
> > #ifdef CONFIG_X86_64
>
> So what happens
On Mon, Mar 22, 2021 at 03:41:40PM +0900, Masami Hiramatsu wrote:
> ".global kretprobe_trampoline\n"
> ".type kretprobe_trampoline, @function\n"
> "kretprobe_trampoline:\n"
> #ifdef CONFIG_X86_64
So what happens if we get an NMI here? That is, after the RET but before
the push?
This changes x86/kretprobe stack frame on kretprobe_trampoline
a bit, which now push the kretprobe_trampoline as a fake return
address at the bottom of the stack frame. With this fix, the ORC
unwinder will see the kretprobe_trampoline as a return address.
Signed-off-by: Masami Hiramatsu
12 matches
Mail list logo
