From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Andrii Nakryiko <andriin@fb.com>, bpf <bpf@vger.kernel.org>,
Networking <netdev@vger.kernel.org>,
Alexei Starovoitov <ast@fb.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Kernel Team <kernel-team@fb.com>, Hao Luo <haoluo@google.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Song Liu <songliubraving@fb.com>,
Quentin Monnet <quentin@isovalent.com>
Subject: Re: [RFC PATCH bpf-next 8/8] tools/bpftool: show PIDs with FDs open against BPF map/prog/link/btf
Date: Fri, 12 Jun 2020 22:57:59 -0700 [thread overview]
Message-ID: <CAEf4BzaHVRxkiDbTGashiuakXFBRYvDsQmJ0O08xFijKXiAwSg@mail.gmail.com> (raw)
In-Reply-To: <20200613034507.wjhd4z6dsda3pz7c@ast-mbp>
On Fri, Jun 12, 2020 at 8:45 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Fri, Jun 12, 2020 at 03:31:50PM -0700, Andrii Nakryiko wrote:
> > Add bpf_iter-based way to find all the processes that hold open FDs against
> > BPF object (map, prog, link, btf). Add new flag (-o, for "ownership", given
> > -p is already taken) to trigger collection and output of these PIDs.
> >
> > Sample output for each of 4 BPF objects:
> >
> > $ sudo ./bpftool -o prog show
> > 1992: cgroup_skb name egress_alt tag 9ad187367cf2b9e8 gpl
> > loaded_at 2020-06-12T14:18:10-0700 uid 0
> > xlated 48B jited 59B memlock 4096B map_ids 2074
> > btf_id 460
> > pids: 913709,913732,913733,913734
> > 2062: cgroup_device tag 8c42dee26e8cd4c2 gpl
> > loaded_at 2020-06-12T14:37:52-0700 uid 0
> > xlated 648B jited 409B memlock 4096B
> > pids: 1
> >
> > $ sudo ./bpftool -o map show
> > 2074: array name test_cgr.bss flags 0x400
> > key 4B value 8B max_entries 1 memlock 8192B
> > btf_id 460
> > pids: 913709,913732,913733,913734
> >
> > $ sudo ./bpftool -o link show
> > 82: cgroup prog 1992
> > cgroup_id 0 attach_type egress
> > pids: 913709,913732,913733,913734
> > 86: cgroup prog 1992
> > cgroup_id 0 attach_type egress
> > pids: 913709,913732,913733,913734
>
> This is awesome.
Thanks.
>
> Why extra flag though? I think it's so useful that everyone would want to see
No good reason apart from "being safe by default". If turned on by
default, bpftool would need to probe for bpf_iter support first. I can
add probing and do this by default.
> this by default. Also the word 'pid' has kernel meaning or user space meaning?
> Looks like kernel then bpftool should say 'tid'.
No, its process ID in user-space sense. See task->tgid in
pid_iter.bpf.c. I figured thread ID isn't all that useful.
> Could you capture comm as well and sort it by comm, like:
>
> $ sudo ./bpftool link show
> 82: cgroup prog 1992
> cgroup_id 0 attach_type egress
> systemd(1), firewall(913709 913732), logger(913733 913734)
Yep, comm is useful, I'll add that. Grouping by comm is kind of a
pain, though, plus usually there will be one process only. So let me
start with doing comm (pid) for each PID independently. I think that
will be as good in practice.
next prev parent reply other threads:[~2020-06-13 5:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200612223150.1177182-1-andriin@fb.com>
[not found] ` <20200612223150.1177182-9-andriin@fb.com>
2020-06-13 3:45 ` [RFC PATCH bpf-next 8/8] tools/bpftool: show PIDs with FDs open against BPF map/prog/link/btf Alexei Starovoitov
2020-06-13 5:57 ` Andrii Nakryiko [this message]
2020-06-13 22:14 ` Arnaldo Carvalho de Melo
2020-06-15 9:04 ` Toke Høiland-Jørgensen
2020-06-15 9:30 ` Quentin Monnet
[not found] ` <20200612223150.1177182-2-andriin@fb.com>
[not found] ` <CA+khW7hAYVdoQX5-j0z1iGEVZeww4BBu4NXzy5eS5OwDRYqe2w@mail.gmail.com>
2020-06-15 18:55 ` [RFC PATCH bpf-next 1/8] libbpf: generalize libbpf externs support Andrii Nakryiko
[not found] ` <20200612223150.1177182-3-andriin@fb.com>
[not found] ` <CA+khW7hFZzp_K_xydSFw0O3LYB22_fC=Z4wG7i9Si+phGHn4cQ@mail.gmail.com>
2020-06-15 19:08 ` [RFC PATCH bpf-next 2/8] libbpf: add support for extracting kernel symbol addresses Andrii Nakryiko
2020-06-16 8:05 ` Hao Luo
2020-06-17 1:24 ` Hao Luo
2020-06-17 1:36 ` Andrii Nakryiko
2020-06-18 7:53 ` Hao Luo
[not found] ` <20200612223150.1177182-4-andriin@fb.com>
[not found] ` <CA+khW7jxdS1KRpk2syVGjDqbyn3wAd3Eh_LEMAEhkPUehuXMwg@mail.gmail.com>
2020-06-15 19:11 ` [RFC PATCH bpf-next 3/8] selftests/bpf: add __ksym extern selftest Andrii Nakryiko
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=CAEf4BzaHVRxkiDbTGashiuakXFBRYvDsQmJ0O08xFijKXiAwSg@mail.gmail.com \
--to=andrii.nakryiko@gmail.com \
--cc=acme@kernel.org \
--cc=alexei.starovoitov@gmail.com \
--cc=andriin@fb.com \
--cc=ast@fb.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=kernel-team@fb.com \
--cc=netdev@vger.kernel.org \
--cc=quentin@isovalent.com \
--cc=songliubraving@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).