On Wed, May 25, 2022 at 6:23 PM Martin KaFai Lau [off-list ref] wrote:

On Wed, May 25, 2022 at 05:03:40PM -0700, Martin KaFai Lau wrote:

quoted

quoted

But the problem with going link-only is that I'd have to teach bpftool
to use links for BPF_LSM_CGROUP and it brings a bunch of problems:
* I'd have to pin those links somewhere to make them stick around
* Those pin paths essentially become an API now because "detach" now
  depends on them?
* (right now it automatically works with the legacy apis without any
changes)

It is already the current API for all links (tracing, cgroup...).  It goes
away (detach) with the process unless it is pinned.  but yeah, it will
be a new exception in the "bpftool cgroup" subcommand only for
BPF_LSM_CGROUP.

If it is an issue with your use case, may be going back to v6 that extends
the query bpf_attr with attach_btf_id and support both attach API ?

[ hit sent too early... ]
or extending the bpf_prog_info as you also mentioned in the earlier reply.
It seems all have their ups and downs.

I'm thinking on putting everything I need into bpf_prog_info and
exporting a list of attach_flags in prog_query (as it's done here in
v7 + add attach_btf_obj_id).
I'm a bit concerned with special casing bpf_lsm_cgroup even more if we
go with a link-only api :-(
I can definitely also put this info into bpf_link_info, but I'm not
sure what's Andrii's preference? I'm assuming he was suggesting to do
either bpf_prog_info or bpf_link_info, but not both?