All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Andrey Ignatov <rdna@fb.com>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	osandov@fb.com, Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH bpf-next] bpf: Add drgn script to list progs/maps
Date: Wed, 26 Feb 2020 22:27:58 -0800	[thread overview]
Message-ID: <CAEf4BzZo7rmZejxJCT-s3OSiYqMxzP71Q9Xg+x=WFN00Yca0Sw@mail.gmail.com> (raw)
In-Reply-To: <20200227023253.3445221-1-rdna@fb.com>

On Wed, Feb 26, 2020 at 6:33 PM Andrey Ignatov <rdna@fb.com> wrote:
>
> drgn is a debugger that reads kernel memory and uses DWARF to get types
> and symbols. See [1], [2] and [3] for more details on drgn.
>
> Since drgn operates on kernel memory it has access to kernel internals
> that user space doesn't. It allows to get extended info about various
> kernel data structures.
>
> Introduce bpf.py drgn script to list BPF programs and maps and their
> properties unavailable to user space via kernel API.
>
> The main use-case bpf.py covers is to show BPF programs attached to
> other BPF programs via freplace/fentry/fexit mechanisms introduced
> recently. There is no user-space API to get this info and e.g. bpftool
> can only show all BPF programs but can't show if program A replaces a
> function in program B.
>
> Example:
>
>   % sudo tools/bpf/bpf.py p | grep test_pkt_access
>      650: BPF_PROG_TYPE_SCHED_CLS          test_pkt_access
>      654: BPF_PROG_TYPE_TRACING            test_main                        linked:[650->25: BPF_TRAMP_FEXIT test_pkt_access->test_pkt_access()]
>      655: BPF_PROG_TYPE_TRACING            test_subprog1                    linked:[650->29: BPF_TRAMP_FEXIT test_pkt_access->test_pkt_access_subprog1()]
>      656: BPF_PROG_TYPE_TRACING            test_subprog2                    linked:[650->31: BPF_TRAMP_FEXIT test_pkt_access->test_pkt_access_subprog2()]
>      657: BPF_PROG_TYPE_TRACING            test_subprog3                    linked:[650->21: BPF_TRAMP_FEXIT test_pkt_access->test_pkt_access_subprog3()]
>      658: BPF_PROG_TYPE_EXT                new_get_skb_len                  linked:[650->16: BPF_TRAMP_REPLACE test_pkt_access->get_skb_len()]
>      659: BPF_PROG_TYPE_EXT                new_get_skb_ifindex              linked:[650->23: BPF_TRAMP_REPLACE test_pkt_access->get_skb_ifindex()]
>      660: BPF_PROG_TYPE_EXT                new_get_constant                 linked:[650->19: BPF_TRAMP_REPLACE test_pkt_access->get_constant()]
>
> It can be seen that there is a program test_pkt_access, id 650 and there
> are multiple other tracing and ext programs attached to functions in
> test_pkt_access.
>
> For example the line:
>
>      658: BPF_PROG_TYPE_EXT                new_get_skb_len                  linked:[650->16: BPF_TRAMP_REPLACE test_pkt_access->get_skb_len()]
>
> means that BPF program new_get_skb_len, id 658, type BPF_PROG_TYPE_EXT
> replaces (BPF_TRAMP_REPLACE) function get_skb_len() that has BTF id 16
> in BPF program test_pkt_access, prog id 650.
>
> Just very simple output is supported now but it can be extended in the
> future if needed.
>
> The script is extendable and currently implements two subcommands:
> * prog (alias: p) to list all BPF programs;
> * map (alias: m) to list all BPF maps;
>
> Developer can simply tweak the script to print interesting pieces of programs
> or maps.
>
> The name bpf.py is not super authentic. I'm open to better options.

Just to throw another name into consideration: bpf_inspect.py?

>
> The script can be sent to drgn repo where it's easier to maintain its
> "drgn-ness", but in kernel tree it should be easier to maintain BPF
> functionality itself what can be more important in this case.

Unless it's regularly exercised as part of selftests, it will still break, IMO.


>
> The script depends on drgn revision [4] where BPF helpers were added.
>
> More examples of output:
>
>   % sudo tools/bpf/bpf.py p | shuf -n 3
>       81: BPF_PROG_TYPE_CGROUP_SOCK_ADDR   tw_ipt_bind
>       94: BPF_PROG_TYPE_CGROUP_SOCK_ADDR   tw_ipt_bind
>       43: BPF_PROG_TYPE_KPROBE             kprobe__tcp_reno_cong_avoid
>
>   % sudo tools/bpf/bpf.py m | shuf -n 3
>      213: BPF_MAP_TYPE_HASH                errors
>       30: BPF_MAP_TYPE_ARRAY               sslwall_setting
>       41: BPF_MAP_TYPE_LRU_HASH            flow_to_snd
>
> Help:
>
>   % sudo tools/bpf/bpf.py
>   usage: bpf.py [-h] {prog,p,map,m} ...
>
>   drgn script to list BPF programs or maps and their properties
>   unavailable via kernel API.
>
>   See https://github.com/osandov/drgn/ for more details on drgn.
>
>   optional arguments:
>     -h, --help      show this help message and exit
>
>   subcommands:
>     {prog,p,map,m}
>       prog (p)      list BPF programs
>       map (m)       list BPF maps
>
> [1] https://github.com/osandov/drgn/
> [2] https://drgn.readthedocs.io/en/latest/index.html
> [3] https://lwn.net/Articles/789641/
> [4] https://github.com/osandov/drgn/commit/c8ef841768032e36581d45648e42fc2a5489d8f2
>
> Signed-off-by: Andrey Ignatov <rdna@fb.com>
> ---
>  tools/bpf/bpf.py | 149 +++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 149 insertions(+)
>  create mode 100755 tools/bpf/bpf.py
>

[...]

  parent reply	other threads:[~2020-02-27  6:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-27  2:32 [PATCH bpf-next] bpf: Add drgn script to list progs/maps Andrey Ignatov
2020-02-27  5:45 ` Song Liu
2020-02-27 17:01   ` Andrey Ignatov
2020-02-27  6:27 ` Andrii Nakryiko [this message]
2020-02-27 17:38   ` Andrey Ignatov
2020-02-27 18:01 ` Stanislav Fomichev
2020-02-27 18:26   ` Andrey Ignatov
2020-02-27 21:11     ` Daniel Borkmann
2020-02-27 21:32       ` Daniel Borkmann
2020-02-27 22:19         ` Omar Sandoval
2020-02-28 20:11           ` Andrey Ignatov
2020-02-28 21:29             ` Andrey Ignatov
2020-02-28 12:51 ` Quentin Monnet
2020-02-28 20:15   ` Andrey Ignatov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEf4BzZo7rmZejxJCT-s3OSiYqMxzP71Q9Xg+x=WFN00Yca0Sw@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@fb.com \
    --cc=osandov@fb.com \
    --cc=rdna@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.