[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210613030857.72bxw56bv6rwznfk@apollo>
Date: Sun, 13 Jun 2021 08:38:57 +0530
From: Kumar Kartikeya Dwivedi <memxor@...il.com>
To: Cong Wang <xiyou.wangcong@...il.com>
Cc: bpf <bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>,
Jamal Hadi Salim <jhs@...atatu.com>,
Vlad Buslov <vladbu@...dia.com>, Jiri Pirko <jiri@...nulli.us>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, Joe Stringer <joe@...ium.io>,
Quentin Monnet <quentin@...valent.com>,
Jesper Dangaard Brouer <brouer@...hat.com>,
Toke Høiland-Jørgensen <toke@...hat.com>,
Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [PATCH RFC bpf-next 0/7] Add bpf_link based TC-BPF API
On Fri, Jun 11, 2021 at 07:30:49AM IST, Cong Wang wrote:
> I see why you are creating TC filters now, because you are trying to
> force the lifetime of a bpf target to align with the bpf program itself.
> The deeper reason seems to be that a cls_bpf filter looks so small
> that it appears to you that it has nothing but a bpf_prog, right?
>
Just to clarify on this further, BPF program still has its own lifetime, link
takes a reference, and the filter still takes a reference on it (since it
assumes ownership, so it was easier that way).
When releasing the bpf_link if the prog pointer is set, we also detach the TC
filter (which releases its reference on the prog). The link on destruction
releases its reference. So the rest of refcount will depend on userspace
holding/pinning the fd or not.
--
Kartikeya
Powered by blists - more mailing lists