All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	mingo@redhat.com, x86@kernel.org,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	"Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Alexei Starovoitov <ast@fb.com>,
	Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [PATCH -tip v3 3/7] kprobes: Warn if optprobe handler tries to change execution path
Date: Tue, 17 Oct 2017 13:35:59 +0530	[thread overview]
Message-ID: <20171017080559.3exsw66lmetpxg2i@naverao1-tp.localdomain> (raw)
In-Reply-To: <20171012140409.afee6696cff6c546ce7c4351@kernel.org>

On 2017/10/12 05:04AM, Masami Hiramatsu wrote:
> On Tue, 10 Oct 2017 22:32:31 +0530
> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
> 
> > On 2017/09/19 10:00AM, Masami Hiramatsu wrote:
> > So, we don't seem to _require_ users to return !0 if the handler 
> > changes [n]ip? Or to always change [n]ip if returning !0.
> > 
> > The implicit assumption seems to be that the handler returns !0 if it 
> > wants to suppress executing the probed instruction since the handler has 
> > already taken care of that. So, at the least, I think the message should 
> > change. However...
> > 
> > In powerpc, we place a probe on kretprobe_trampoline and optimize it. 
> 
> Oh, what did you do?? I think kretprobe_trampoline just calls
> its handler to get correct address to return and just return to it.

For x86 yes, but on powerpc, we use the original implementation of 
placing a probe at kretprobe_trampoline for catching the function 
return.

> 
> > This works for us (even though optprobes doesn't "honour" changes to 
> > [n]ip). See commit 762df10bad6954 ("powerpc/kprobes: Optimize kprobe in 
> > kretprobe_trampoline()"). With this patch, we are now seeing a warning 
> > (thanks to mpe for the report):
> > 
> > [  520.144449] ------------[ cut here ]------------
> > [  520.144676] WARNING: CPU: 2 PID: 6355 at kernel/kprobes.c:391 opt_pre_handler+0xe8/0x110
> > ...
> > [  520.151806] CPU: 2 PID: 6355 Comm: ftracetest Not tainted 4.14.0-rc4-gcc6-next-20171009-g49827b9 #1
> > [  520.152097] task: c0000000e9ddfb80 task.stack: c0000000f881c000
> > [  520.152291] NIP:  c0000000001f3b78 LR: c0000000001f3b2c CTR: 
> > c0000000002436a0
> > [  520.152527] REGS: c0000000f881f7f0 TRAP: 0700   Not tainted  (4.14.0-rc4-gcc6-next-20171009-g49827b9)
> > [  520.152818] MSR:  8000000100021033 <SF,ME,IR,DR,RI,LE,TM[E]>  CR: 24002824  XER: 20000000
> > [  520.153080] CFAR: c0000000001f3b34 SOFTE: 0
> > ...
> > [  520.155113] NIP [c0000000001f3b78] opt_pre_handler+0xe8/0x110
> > [  520.155320] LR [c0000000001f3b2c] opt_pre_handler+0x9c/0x110
> > [  520.155510] Call Trace:
> > [  520.155590] [c0000000f881fa70] [c0000000001f3b2c] opt_pre_handler+0x9c/0x110 (unreliable)
> > [  520.155825] [c0000000f881fb00] [c000000000047de8] optimized_callback+0xc8/0xe0
> > [  520.156047] [c0000000f881fb40] [c000000000048764] optinsn_slot+0xec/0x10000
> > [  520.156238] [c0000000f881fe30] [c000000000046cb0] kretprobe_trampoline+0x0/0x10
> > [  520.156452] Instruction dump:
> > [  520.156570] 7fbef840 409effa4 38210090 e8010010 eb41ffd0 eb61ffd8 eb81ffe0 eba1ffe8
> > [  520.156792] ebc1fff0 ebe1fff8 7c0803a6 4e800020 <0fe00000> e89e0028 3c62ffce 386362b0
> > [  520.157016] ---[ end trace d8cda029528a560d ]---
> > [  520.157172] Optprobe ignores instruction pointer changing.(kretprobe_trampoline+0x0/0x10)
> > 
> > 
> > So, should this patch be reverted?
> 
> Hmm, I got it. It seems to depend on arch implementation.

Yes, we're optimizing the probe at kretprobe_trampoline, so we need 
this.

> Anyway, this is just adding an warning, we can safely revert it.
> And the documentation should be updated.
> 
> Ingo, could you revert this change?

Thanks!
I will send a patch to revert this change.


- Naveen

  reply	other threads:[~2017-10-17  8:06 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-19  9:58 [PATCH -tip v3 0/7] kprobes/x86: Preempt related enhancements Masami Hiramatsu
2017-09-19  9:59 ` [PATCH -tip v3 1/7] kprobes: Improve smoke test to check preemptible Masami Hiramatsu
2017-09-28 10:52   ` [tip:perf/core] kprobes: Improve smoke test to check preemptibility tip-bot for Masami Hiramatsu
2017-09-19  9:59 ` [PATCH -tip v3 2/7] kprobes/x86: Move get_kprobe_ctlblk in irq-disabled block Masami Hiramatsu
2017-09-28 10:52   ` [tip:perf/core] kprobes/x86: Move the get_kprobe_ctlblk() into " tip-bot for Masami Hiramatsu
2017-09-19 10:00 ` [PATCH -tip v3 3/7] kprobes: Warn if optprobe handler tries to change execution path Masami Hiramatsu
2017-09-28 10:53   ` [tip:perf/core] " tip-bot for Masami Hiramatsu
2017-10-10 17:02   ` [PATCH -tip v3 3/7] " Naveen N. Rao
2017-10-12  5:04     ` Masami Hiramatsu
2017-10-17  8:05       ` Naveen N. Rao [this message]
2017-09-19 10:00 ` [PATCH -tip v3 4/7] kprobes/x86: Disable preempt in optprobe Masami Hiramatsu
2017-09-28 10:53   ` [tip:perf/core] kprobes/x86: Disable preemption " tip-bot for Masami Hiramatsu
2017-09-19 10:01 ` [PATCH -tip v3 5/7] kprobes/x86: Disable preempt ftrace-based jprobe Masami Hiramatsu
2017-09-28 10:54   ` [tip:perf/core] kprobes/x86: Disable preemption in ftrace-based jprobes tip-bot for Masami Hiramatsu
2017-09-19 10:02 ` [PATCH -tip v3 6/7] kprobes/x86: Remove disable_irq from ftrace-based/optimized kprobe Masami Hiramatsu
2017-09-28  7:25   ` Ingo Molnar
2017-09-29  6:48     ` Masami Hiramatsu
2017-09-28 10:54   ` [tip:perf/core] kprobes/x86: Remove IRQ disabling from ftrace-based/optimized kprobes tip-bot for Masami Hiramatsu
2017-09-19 10:03 ` [PATCH -tip v3 7/7] kprobes: Use synchronize_rcu_tasks() for optprobe with CONFIG_PREEMPT Masami Hiramatsu
2017-09-28  7:22   ` Ingo Molnar
2017-09-29  7:29     ` Masami Hiramatsu
2017-09-29  7:37       ` Ingo Molnar
2017-09-29 14:44         ` Masami Hiramatsu
2017-09-29 17:45           ` Ingo Molnar
2017-09-30  5:12             ` Masami Hiramatsu
2017-10-03 23:57       ` Steven Rostedt
2017-10-04 14:01         ` Masami Hiramatsu
2017-09-21 22:00 ` [PATCH -tip v3 0/7] kprobes/x86: Preempt related enhancements Alexei Starovoitov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171017080559.3exsw66lmetpxg2i@naverao1-tp.localdomain \
    --to=naveen.n.rao@linux.vnet.ibm.com \
    --cc=ananth@linux.vnet.ibm.com \
    --cc=ast@fb.com \
    --cc=ast@kernel.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.