[3r7j6qzi9jvnve]

> --I ran ctags across the linux kernel source code, pulled out all the signatures and then reference the signature when compiling the query, so you don't have to do a bunch of casts in the query.

note you don't need the casts if you use kfuncs instead, which also let you reference arguments by name (from https://github.com/bpftrace/bpftrace/blob/master/man/adoc/bp... ):

    kfunc:tcp_connect {
        if (args->sk->__sk_common.skc_daddr == (uint32)pton("127.0.0.1"))
            ...
    }

With that said, kfuncs don't work (yet?) on aarch64, so this is great for me -- I'll definitely give it a try next time I need it.

(EDIT: formatting)

[knuckleheads]

oh sick! thank you for letting me know. I will look into using this more for sure. I am curious, do you know if there is a way to access the arguments for kfuncs ahead of time? does the kernel provide this information somehow at runtime, or is it all still implicit?

Also, you might also enjoy https://github.com/zmaril/hancock which is some of the code I've been using to run ctags across the versions of the kernel.

(edit: I checked bpftrace -l and saw that it does have the arguments and type structs ahead of time, which is absolutely perfect, thank you very much! Super helpful.)

[evgpbfhnr]

Try this:

    bpftrace -lv kfunc:*

(or any specific function instead of wildcard) will get you all kfuncs and their respective arguments.

output snippet:

    kfunc:vmlinux:tcp_conn_request
        struct request_sock_ops * rsk_ops
        const struct tcp_request_sock_ops * af_ops
        struct sock * sk
        struct sk_buff * skb
        int retval
    kfunc:vmlinux:tcp_connect
        struct sock * sk
        int retval
    kfunc:vmlinux:tcp_create_openreq_child
        const struct sock * sk
        struct request_sock * req
        struct sk_buff * skb
        struct sock * retval

I'm not sure how to get this info without bpftrace itself - bpftool might have the info available somehow?

[knuckleheads]

That’s awesome! Very helpful, thank you. I had been holding off on parsing that output and combining it with vmlinux.h, but that just jumped up way higher priority. Thanks again!