Re: [External] Re: [PATCH bpf-next v2 1/9] bpf: tracing: add support to record and check the accessed args

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 1 Apr 2024 10:28:17 +0800
梦龙董 <dongmenglong.8@xxxxxxxxxxxxx> wrote:

> On Sun, Mar 31, 2024 at 3:34 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> >
> > On Sat, 30 Mar 2024 11:18:29 +0800
> > 梦龙董 <dongmenglong.8@xxxxxxxxxxxxx> 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?

If you add a ftrace_ops function handler that calls a BPF program, I don't
see why you can't just give it the parameters it needs instead of using bpf
helpers. It's no different than using a trampoline to do the same thing.

-- Steve





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux