[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220526012330.dnicj2mrdlr4o6oo@kafai-mbp>
Date: Wed, 25 May 2022 18:23:30 -0700
From: Martin KaFai Lau <kafai@...com>
To: sdf@...gle.com
Cc: Andrii Nakryiko <andrii.nakryiko@...il.com>,
Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>
Subject: Re: [PATCH bpf-next v7 05/11] bpf: implement BPF_PROG_QUERY for
BPF_LSM_CGROUP
On Wed, May 25, 2022 at 05:03:40PM -0700, Martin KaFai Lau wrote:
> > 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.
Powered by blists - more mailing lists