Re: [PATCH bpf-next v7 07/11] libbpf: implement bpf_prog_query_opts

[Martin KaFai Lau <kafai@fb.com>]

On Mon, May 23, 2022 at 08:45:13PM -0700, Andrii Nakryiko wrote:
> On Mon, May 23, 2022 at 7:15 PM Stanislav Fomichev <sdf@google.com> wrote:
> >
> > On Mon, May 23, 2022 at 4:22 PM Andrii Nakryiko
> > <andrii.nakryiko@gmail.com> wrote:
> > >
> > > On Wed, May 18, 2022 at 3:55 PM Stanislav Fomichev <sdf@google.com> wrote:
> > > >
> > > > Implement bpf_prog_query_opts as a more expendable version of
> > > > bpf_prog_query. Expose new prog_attach_flags and attach_btf_func_id as
> > > > well:
> > > >
> > > > * prog_attach_flags is a per-program attach_type; relevant only for
> > > >   lsm cgroup program which might have different attach_flags
> > > >   per attach_btf_id
> > > > * attach_btf_func_id is a new field expose for prog_query which
> > > >   specifies real btf function id for lsm cgroup attachments
> > > >
> > >
> > > just thoughts aloud... Shouldn't bpf_prog_query() also return link_id
> > > if the attachment was done with LINK_CREATE? And then attach flags
> > > could actually be fetched through corresponding struct bpf_link_info.
> > > That is, bpf_prog_query() returns a list of link_ids, and whatever
> > > link-specific information can be fetched by querying individual links.
> > > Seems more logical (and useful overall) to extend struct bpf_link_info
> > > (you can get it more generically from bpftool, by querying fdinfo,
> > > etc).
> >
> > Note that I haven't removed non-link-based APIs because they are easy
> > to support. That might be an argument in favor of dropping them.
> > Regarding the implementation: I'm not sure there is an easy way, in
> > the kernel, to find all links associated with a given bpf_prog?
> 
> Nope, kernel doesn't keep track of this explicitly, in general. If you
> were building a tool for something like that you'd probably use
> bpf_link iterator program which we recently added. But in this case
> kernel knows links that are attached to cgroups (they are in
> prog_item->link if it's not NULL), so you shouldn't need any extra
> information.
It will be useful to be able to figure out the effective
bpf progs of a cgroup.  Something that the bpftool currently supports.
With links, the usespace can probably figure that out by
knowing how the kernel evaluate the effective array and
doing it similarly in the userspace ?

or it is something that fits better with cgroup iter in the future.