Messages in this thread | | | From | 梦龙董 <> | Date | Mon, 1 Apr 2024 10:28:17 +0800 | Subject | Re: [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 > >
| |