On 2025/8/28 00:21 Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> write: > On Wed, Aug 27, 2025 at 5:38 AM Menglong Dong <menglong8.dong@xxxxxxxxx> wrote: > > > > Preemption is disabled in ftrace graph, which indicate rcu_read_lock. So > > the rcu_read_lock is not needed in fprobe_entry(), and it is not needed > > in kprobe_multi_link_prog_run() neither. > > kprobe_busy_begin() doing preempt_disable() is an implementation > detail that might change. > Having explicit rcu_read_lock() doesn't hurt. > It's a nop anyway in PREEMPT_NONE. Ok, I see. Thanks~ > > pw-bot: cr > > > Signed-off-by: Menglong Dong <dongml2@xxxxxxxxxxxxxxx> > > --- > > kernel/trace/bpf_trace.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c > > index 606007c387c5..0e79fa84a634 100644 > > --- a/kernel/trace/bpf_trace.c > > +++ b/kernel/trace/bpf_trace.c > > @@ -2741,12 +2741,10 @@ kprobe_multi_link_prog_run(struct bpf_kprobe_multi_link *link, > > goto out; > > } > > > > - rcu_read_lock(); > > regs = ftrace_partial_regs(fregs, bpf_kprobe_multi_pt_regs_ptr()); > > old_run_ctx = bpf_set_run_ctx(&run_ctx.session_ctx.run_ctx); > > err = bpf_prog_run(link->link.prog, regs); > > bpf_reset_run_ctx(old_run_ctx); > > - rcu_read_unlock(); > > > > out: > > __this_cpu_dec(bpf_prog_active); > > -- > > 2.51.0 > > > >
