All of lore.kernel.org
 help / color / mirror / Atom feed
From: Menglong Dong <menglong.dong@linux.dev>
To: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@kernel.org>,
	Menglong Dong <menglong8.dong@gmail.com>,
	jolsa@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
	hpa@zytor.com, kees@kernel.org, samitolvanen@google.com,
	rppt@kernel.org, luto@kernel.org, mhiramat@kernel.org,
	ast@kernel.org, andrii@kernel.org, linux-kernel@vger.kernel.org,
	bpf@vger.kernel.org
Subject: Re: [PATCH] tracing: fgraph: Protect return handler from recursion loop
Date: Sat, 20 Sep 2025 21:39:25 +0800	[thread overview]
Message-ID: <5974303.DvuYhMxLoT@7950hx> (raw)
In-Reply-To: <175828305637.117978.4183947592750468265.stgit@devnote2>

On 2025/9/19 19:57, Masami Hiramatsu (Google) wrote:
> From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> 
> function_graph_enter_regs() prevents itself from recursion by
> ftrace_test_recursion_trylock(), but __ftrace_return_to_handler(),
> which is called at the exit, does not prevent such recursion.
> Therefore, while it can prevent recursive calls from
> fgraph_ops::entryfunc(), it is not able to prevent recursive calls
> to fgraph from fgraph_ops::retfunc(), resulting in a recursive loop.
> This can lead an unexpected recursion bug reported by Menglong.
> 
>  is_endbr() is called in __ftrace_return_to_handler -> fprobe_return
>   -> kprobe_multi_link_exit_handler -> is_endbr.
> 
> To fix this issue, acquire ftrace_test_recursion_trylock() in the
> __ftrace_return_to_handler() after unwind the shadow stack to mark
> this section must prevent recursive call of fgraph inside user-defined
> fgraph_ops::retfunc().
> 
> This is essentially a fix to commit 4346ba160409 ("fprobe: Rewrite
> fprobe on function-graph tracer"), because before that fgraph was
> only used from the function graph tracer. Fprobe allowed user to run
> any callbacks from fgraph after that commit.
> 
> Reported-by: Menglong Dong <menglong8.dong@gmail.com>
> Closes: https://lore.kernel.org/all/20250918120939.1706585-1-dongml2@chinatelecom.cn/
> Fixes: 4346ba160409 ("fprobe: Rewrite fprobe on function-graph tracer")
> Cc: stable@vger.kernel.org
> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> ---
>  kernel/trace/fgraph.c |   12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/kernel/trace/fgraph.c b/kernel/trace/fgraph.c
> index 1e3b32b1e82c..08dde420635b 100644
> --- a/kernel/trace/fgraph.c
> +++ b/kernel/trace/fgraph.c
> @@ -815,6 +815,7 @@ __ftrace_return_to_handler(struct ftrace_regs *fregs, unsigned long frame_pointe
>  	unsigned long bitmap;
>  	unsigned long ret;
>  	int offset;
> +	int bit;
>  	int i;
>  
>  	ret_stack = ftrace_pop_return_trace(&trace, &ret, frame_pointer, &offset);
> @@ -829,6 +830,15 @@ __ftrace_return_to_handler(struct ftrace_regs *fregs, unsigned long frame_pointe
>  	if (fregs)
>  		ftrace_regs_set_instruction_pointer(fregs, ret);
>  
> +	bit = ftrace_test_recursion_trylock(trace.func, ret);
> +	/*
> +	 * This must be succeeded because the entry handler returns before
> +	 * modifying the return address if it is nested. Anyway, we need to
> +	 * avoid calling user callbacks if it is nested.
> +	 */
> +	if (WARN_ON_ONCE(bit < 0))
> +		goto out;

Hi, the logic seems right, but the warning is triggered when
I try to run the bpf bench testing:

$ ./benchs/run_bench_trigger.sh kretprobe-multi-all
[   20.619642] NOTICE: Automounting of tracing to debugfs is deprecated and will be removed in 2030
[  139.509036] ------------[ cut here ]------------
[  139.509180] WARNING: CPU: 2 PID: 522 at kernel/trace/fgraph.c:839 ftrace_return_to_handler+0x2b9/0x2d0
[  139.509411] Modules linked in: virtio_net
[  139.509514] CPU: 2 UID: 0 PID: 522 Comm: bench Not tainted 6.17.0-rc5-g1fe6d652bfa0 #106 NONE 
[  139.509720] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-1-1 04/01/2014
[  139.509948] RIP: 0010:ftrace_return_to_handler+0x2b9/0x2d0
[  139.510086] Code: e8 0c 08 0e 00 0f 0b 49 c7 c1 00 73 20 81 e9 d1 fe ff ff 40 f6 c6 10 75 11 49 c7 c3 ef ff ff ff ba 10 00 00 00 e9 57 fe ff ff <0f> 0b e9 a5 fe ff ff e8 1b 72 0d 01 66 66 2e 0f 1f 84 00 00 00 00
[  139.510536] RSP: 0018:ffffc9000012cef8 EFLAGS: 00010002
[  139.510664] RAX: ffff88810f709800 RBX: ffffc900007c3678 RCX: 0000000000000003
[  139.510835] RDX: 0000000000000008 RSI: 0000000000000018 RDI: 0000000000000000
[  139.511007] RBP: 0000000000000000 R08: 0000000000000034 R09: ffffffff82550319
[  139.511184] R10: ffffc9000012cf50 R11: fffffffffffffff7 R12: 0000000000000000
[  139.511357] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[  139.511532] FS:  00007fe58276fb00(0000) GS:ffff8884ab3b8000(0000) knlGS:0000000000000000
[  139.511724] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  139.511865] CR2: 0000562a28314b67 CR3: 00000001143f9000 CR4: 0000000000750ef0
[  139.512038] PKRU: 55555554
[  139.512106] Call Trace:
[  139.512177]  <IRQ>
[  139.512232]  ? irq_exit_rcu+0x4/0xb0
[  139.512322]  return_to_handler+0x1e/0x50
[  139.512422]  ? idle_cpu+0x9/0x50
[  139.512506]  ? sysvec_apic_timer_interrupt+0x69/0x80
[  139.512638]  ? idle_cpu+0x9/0x50
[  139.512731]  ? irq_exit_rcu+0x3a/0xb0
[  139.512833]  ? ftrace_stub_direct_tramp+0x10/0x10
[  139.512961]  ? sysvec_apic_timer_interrupt+0x69/0x80
[  139.513101]  </IRQ>
[  139.513168]  <TASK>

> +
>  #ifdef CONFIG_FUNCTION_GRAPH_RETVAL
>  	trace.retval = ftrace_regs_get_return_value(fregs);
>  #endif
> @@ -852,6 +862,8 @@ __ftrace_return_to_handler(struct ftrace_regs *fregs, unsigned long frame_pointe
>  		}
>  	}
>  
> +	ftrace_test_recursion_unlock(bit);
> +out:
>  	/*
>  	 * The ftrace_graph_return() may still access the current
>  	 * ret_stack structure, we need to make sure the update of
> 
> 
> 





  parent reply	other threads:[~2025-09-20 13:39 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-18 12:09 [PATCH] x86/ibt: make is_endbr() notrace Menglong Dong
2025-09-18 13:05 ` Peter Zijlstra
2025-09-18 13:32   ` Menglong Dong
2025-09-18 16:02     ` Alexei Starovoitov
2025-09-18 16:59       ` Peter Zijlstra
2025-09-18 17:53         ` Alexei Starovoitov
2025-09-19  1:13           ` Menglong Dong
2025-09-22  6:52             ` Peter Zijlstra
2025-09-22  7:13               ` menglong.dong
2025-09-22  7:19                 ` Peter Zijlstra
2025-09-22  7:21                   ` Menglong Dong
2025-09-22  6:36           ` Peter Zijlstra
2025-09-18 16:56     ` Peter Zijlstra
2025-09-19 12:35       ` Masami Hiramatsu
2025-09-19  8:52 ` Masami Hiramatsu
2025-09-19  8:58   ` Menglong Dong
2025-09-19 12:32     ` Masami Hiramatsu
2025-09-19 11:57 ` [PATCH] tracing: fgraph: Protect return handler from recursion loop Masami Hiramatsu (Google)
2025-09-19 15:27   ` Steven Rostedt
2025-09-20  7:45     ` Jiri Olsa
2025-09-22  6:16       ` Masami Hiramatsu
2025-09-22 13:38         ` Jiri Olsa
2025-09-22 14:42           ` Steven Rostedt
2025-09-22 19:45           ` Jiri Olsa
2025-09-21  4:05     ` Masami Hiramatsu
2025-09-21 22:52       ` Steven Rostedt
2025-09-24 22:58         ` Masami Hiramatsu
2025-09-20 13:39   ` Menglong Dong [this message]
2025-09-21  4:06     ` Masami Hiramatsu
2025-09-21 23:00       ` Steven Rostedt
2025-09-24 22:59         ` Masami Hiramatsu
2025-09-22  5:19     ` Masami Hiramatsu

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=5974303.DvuYhMxLoT@7950hx \
    --to=menglong.dong@linux.dev \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bp@alien8.de \
    --cc=bpf@vger.kernel.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jolsa@kernel.org \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=menglong8.dong@gmail.com \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@kernel.org \
    --cc=rppt@kernel.org \
    --cc=samitolvanen@google.com \
    --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.