Re: [RFC PATCH bpf-next 0/8] bpf_link observability APIs

[Andrii Nakryiko <andrii.nakryiko@gmail.com>]

On Sun, Apr 5, 2020 at 9:26 AM David Ahern <dsahern@gmail.com> wrote:
>
> On 4/3/20 6:09 PM, Andrii Nakryiko wrote:
> > This patch series adds various observability APIs to bpf_link:
> >   - each bpf_link now gets ID, similar to bpf_map and bpf_prog, by which
> >     user-space can iterate over all existing bpf_links and create limited FD
> >     from ID;
> >   - allows to get extra object information with bpf_link general and
> >     type-specific information;
> >   - makes LINK_UPDATE operation allowed only for writable bpf_links and allows
> >     to pin bpf_link as read-only file;
> >   - implements `bpf link show` command which lists all active bpf_links in the
> >     system;
> >   - implements `bpf link pin` allowing to pin bpf_link by ID or from other
> >     pinned path.
> >
> > This RFC series is missing selftests and only limited amount of manual testing
> > was performed. But kernel implementation is hopefully in a good shape and
> > won't change much (unless some big issues are identified with the current
> > approach). It would be great to get feedback on approach and implementation,
> > before I invest more time in writing tests.
> >
>
> The word 'ownership' was used over and over in describing the benefits
> of bpf_link meaning a process owns a program at a specific attach point.
> How does this set allow me to discover the pid of the process
> controlling a specific bpf_link?

In general, it's many processes, not a single process. Here's how:

1. Each bpf_link has a unique ID.
2. You can find desired bpf_link info (including ID) either by already
having FD and querying it with GET_OBJ_INFO_BY_FD, or by doing
GET_NEXT_ID iteration and then GET_FD_BY_ID + GET_OBJ_INFO_BY_FD.
3. Iterate all open files (either by using tools like drgn or by
iterating over procfs), check their fdinfo to see if it's bpf_link's
with given ID. This gives you which application has FD open against
given bpf_link.

Similarly one can iterate over all pinned files in bpffs and see if it
pins bpf_link (I believe bpftool can do that already and show which
objects are pinned, so it should be a minimal change to actually print
out all the pinned file paths).

Does that answer your question?