Re: [PATCH bpf-next 0/3] bpf: Populate bpffs with map and prog iterators

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes:

> 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.

I thought I did, but this seemed to be something that implied I was
wrong, so figured maybe I missed something.

>> > 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.

Right, sure, but in that case A can presumably restart their application
and get it back. Whereas in this case that's not possible, short of
clearing the whole bpffs and remounting it. Would it be possible to
re-trigger the UMH on an existing fs, say by issuing 'mount -o remount
bpf /sys/fs/bpf' (or some other debug mechanism)?

-Toke





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux