lkml.org 
[lkml]   [2024]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [External] Re: [PATCH bpf-next v2 1/9] bpf: tracing: add support to record and check the accessed args
On Sun, Mar 31, 2024 at 3:34 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Sat, 30 Mar 2024 11:18:29 +0800
> 梦龙董 <dongmenglong.8@bytedance.com> wrote:
>
> > > If you really want to have thousands of functions, why not just register it
> > > with ftrace itself. It will give you the arguments via the ftrace_regs
> > > structure. Can't you just register a program as the callback?
> > >
> >
> > Ennn...I don't understand. The main purpose for
> > me to use TRACING is:
> >
> > 1. we can directly access the memory, which is more
> > efficient.
>
> I'm not sure what you mean by the above. Access what memory?
>

We need to use the helper of bpf_probe_read_kernel
when we read "skb->sk" in kprobe, and the "skb" is the
1st arg in ip_rcv(). And we can directly read "skb->sk"
in tracing, which is more efficient. Isn't it?

> > 2. we can obtain the function args in FEXIT, which
> > kretprobe can't do it. And this is the main reason.
>
> I didn't mention kretprobe. If you need access to the exit of the function,
> you can use Masami's fgraph update.
>
> fentry -> ftrace_trampoline -> your_code
>
> For fgraph:
>
> fentry -> ftrace_trampoline -> fgraph [sets up return call] -> your_entry_code
>
> function ret -> fgraph_ret_handler -> your_exit_code
>
> And you will be able to pass data from the entry to the exit code,
> including parameters.

Yeah, the fgraph sounds like a nice solution to my problem.
I'll have a try on it.

Thanks!
Menglong Dong

>
> -- Steve
>
>

\
 
 \ /
  Last update: 2024-05-27 16:17    [W:0.077 / U:0.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site