On Fri, Jul 03, 2020 at 01:18:43PM +0200, Toke Høiland-Jørgensen wrote: > > The user mode driver will load BPF Type Formats, create BPF maps, populate BPF > > maps, load two BPF programs, attach them to BPF iterators, and finally send two > > bpf_link IDs back to the kernel. > > The kernel will pin two bpf_links into newly mounted bpffs instance under > > names "progs" and "maps". These two files become human readable. > > > > $ cat /sys/fs/bpf/progs > > id name pages attached > > 11 dump_bpf_map 1 bpf_iter_bpf_map > > 12 dump_bpf_prog 1 bpf_iter_bpf_prog > > 27 test_pkt_access 1 > > 32 test_main 1 test_pkt_access test_pkt_access > > 33 test_subprog1 1 test_pkt_access_subprog1 test_pkt_access > > 34 test_subprog2 1 test_pkt_access_subprog2 test_pkt_access > > 35 test_subprog3 1 test_pkt_access_subprog3 test_pkt_access > > 36 new_get_skb_len 1 get_skb_len test_pkt_access > > 37 new_get_skb_ifi 1 get_skb_ifindex test_pkt_access > > 38 new_get_constan 1 get_constant test_pkt_access > > Do the iterators respect namespace boundaries? Or will I see all > programs/maps on the host if I cat the file inside a container? why are you asking? I'm pretty sure you know that bpf infra isn't namespaced yet. > > Few interesting observations: > > - though bpffs comes with two human readble files "progs" and "maps" they > > can be removed. 'rm -f /sys/fs/bpf/progs' will remove bpf_link and kernel > > will automatically unload corresponding BPF progs, maps, BTFs. > > Is there any way to get the files back if one does this by mistake > (other than re-mounting the bpffs)? Same as user A pining their prog/map/link in bpffs and user B removing it.
