Documentation/kprobes: Add how to change the execution path (dcce32d9) · Commits · 戴 / test

Add a section that explaining how to change the execution path with kprobes and warnings for some arch. Signed-off-by:

Masami Hiramatsu <mhiramat@kernel.org> Acked-by:

Thomas Gleixner <tglx@linutronix.de> Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: linux-arch@vger.kernel.org Cc: linux-doc@vger.kernel.org Link: https://lore.kernel.org/lkml/152942500680.15209.12374262914863044775.stgit@devbox Signed-off-by:

Ingo Molnar <mingo@kernel.org>

Documentation/kprobes.txt

+20 −0

Original line number	Diff line number	Diff line
		@@ -80,6 +80,26 @@ After the instruction is single-stepped, Kprobes executes the
		"post_handler," if any, that is associated with the kprobe.
		Execution then continues with the instruction following the probepoint.

		Changing Execution Path
		-----------------------

		Since the kprobes can probe into a running kernel code, it can change
		the register set, including instruction pointer. This operation
		requires maximum attention, such as keeping the stack frame, recovering
		execution path etc. Since it is operated on running kernel and need deep
		knowladge of the archtecture and concurrent computing, you can easily
		shot your foot.

		If you change the instruction pointer (and set up other related
		registers) in pre_handler, you must return !0 so that the kprobes
		stops single stepping and just returns to given address.
		This also means post_handler should not be called anymore.

		Note that this operation may be harder on some architectures which
		use TOC (Table of Contents) for function call, since you have to
		setup new TOC for your function in your module, and recover old
		one after back from it.

		Return Probes
		-------------

Admin message