Thread (54 messages) 54 messages, 5 authors, 2022-05-31

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

From: Martin KaFai Lau <hidden>
Date: 2022-05-24 04:01:27
Also in: bpf

On Mon, May 23, 2022 at 08:45:13PM -0700, Andrii Nakryiko wrote:
On Mon, May 23, 2022 at 7:15 PM Stanislav Fomichev [off-list ref] wrote:
quoted
On Mon, May 23, 2022 at 4:22 PM Andrii Nakryiko
[off-list ref] wrote:
quoted
On Wed, May 18, 2022 at 3:55 PM Stanislav Fomichev [off-list ref] wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help