On Mon, Jun 22, 2020 at 5:24 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Fri, Jun 19, 2020 at 04:17:02PM -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). bpftool always attempts to discover this, > > but will silently give up if kernel doesn't yet support bpf_iter BPF programs. > > Process name and PID are emitted for each process (task group). > > > > Sample output for each of 4 BPF objects: > > > > $ sudo ./bpftool prog show > > 2694: cgroup_device tag 8c42dee26e8cd4c2 gpl > > loaded_at 2020-06-16T15:34:32-0700 uid 0 > > xlated 648B jited 409B memlock 4096B > > pids systemd(1) > > 2907: cgroup_skb name egress tag 9ad187367cf2b9e8 gpl > > loaded_at 2020-06-16T18:06:54-0700 uid 0 > > xlated 48B jited 59B memlock 4096B map_ids 2436 > > btf_id 1202 > > pids test_progs(2238417), test_progs(2238445) > > > > $ sudo ./bpftool map show > > 2436: array name test_cgr.bss flags 0x400 > > key 4B value 8B max_entries 1 memlock 8192B > > btf_id 1202 > > pids test_progs(2238417), test_progs(2238445) > > 2445: array name pid_iter.rodata flags 0x480 > > key 4B value 4B max_entries 1 memlock 8192B > > btf_id 1214 frozen > > pids bpftool(2239612) > > Overall it's a massive improvement, so I've applied the set. > > But above 'map show' probably needs a comment in the output. > bpftool is showing a map that was loaded temporarily. > It doesn't do so for programs though. Yeah, and that confused me enough to just spend a bunch of time trying to understand why. It seems like all the files are closed properly and it just so happens that program and link is cleaned up in kernel soon enough for bpftool to never get it with BPF_PROG_GET_NEXT_ID, while map and btf destruction is delayed and they do get returned. > I think somehow highlighting that above map is bpftool's own map > that was used to generate this output would be good. > Filtering it completely out is probably not correct. If you have an example of a message you'd like to see, let me know. But given detecting that this is a "special bpftool's" map/btf is the same as filtering out in terms of reliability (e.g., by PID or by map/btf id), I actually think that filtering it out would be less confusing (and simpler for bpftool output code). > > > $ sudo ./bpftool btf show > > 1202: size 1527B prog_ids 2908,2907 map_ids 2436 > > pids test_progs(2238417), test_progs(2238445) > > 1242: size 34684B > > pids bpftool(2258892) > > similar. > > I've also noticed that 'test_progs -t btf_map_in_map' leaks 'inner_map2'. > Doesn't look like the test is pinning it, so I'm guessing > a recent kernel regression? I haven't debugged it. Yep, neither it's pinned, nor any process has an FD open against it, so must be kernel reference leak...
