fprobes: Add a comment why fprobe_kprobe_handler exits if kprobe is running
authorMasami Hiramatsu (Google) <mhiramat@kernel.org>
Fri, 7 Jul 2023 16:38:03 +0000 (01:38 +0900)
committerMasami Hiramatsu (Google) <mhiramat@kernel.org>
Thu, 13 Jul 2023 15:24:00 +0000 (00:24 +0900)
Add a comment the reason why fprobe_kprobe_handler() exits if any other
kprobe is running.

Link: https://lore.kernel.org/all/168874788299.159442.2485957441413653858.stgit@devnote2/
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Link: https://lore.kernel.org/all/20230706120916.3c6abf15@gandalf.local.home/
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
kernel/trace/fprobe.c

index 2571f7f3d5f28866bd2d6a2053146c3a4180a595..59321d22f43ef0f86490b5bf955917da0d3b5dc8 100644 (file)
@@ -100,6 +100,12 @@ static void fprobe_kprobe_handler(unsigned long ip, unsigned long parent_ip,
                return;
        }
 
+       /*
+        * This user handler is shared with other kprobes and is not expected to be
+        * called recursively. So if any other kprobe handler is running, this will
+        * exit as kprobe does. See the section 'Share the callbacks with kprobes'
+        * in Documentation/trace/fprobe.rst for more information.
+        */
        if (unlikely(kprobe_running())) {
                fp->nmissed++;
                goto recursion_unlock;