From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: 梦龙董 <dongmenglong.8@bytedance.com>
Cc: Andrii Nakryiko <andrii@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <martin.lau@linux.dev>,
Eddy Z <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
"David S. Miller" <davem@davemloft.net>,
David Ahern <dsahern@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
X86 ML <x86@kernel.org>, Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Quentin Monnet <quentin@isovalent.com>,
bpf <bpf@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
linux-s390 <linux-s390@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
linux-trace-kernel@vger.kernel.org,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [External] Re: [PATCH bpf-next v2 7/9] libbpf: don't free btf if program of multi-link tracing existing
Date: Mon, 11 Mar 2024 19:13:05 -0700 [thread overview]
Message-ID: <CAADnVQKsrLB-2bD53R4ZdzUVdx1aqkgom1rzGCGKK0M3Uc+csQ@mail.gmail.com> (raw)
In-Reply-To: <CALz3k9iabeOwHSrPb9mkfCuOebanh3+bAfi7xh3kBBN0DzHC3A@mail.gmail.com>
On Mon, Mar 11, 2024 at 7:05 PM 梦龙董 <dongmenglong.8@bytedance.com> wrote:
>
> > >
> > > +LIBBPF_API void bpf_object__free_btfs(struct bpf_object *obj);
> > > +
> >
> > It shouldn't be exported.
> > libbpf should clean it up when bpf_object is freed.
>
> Yes, libbpf will clean up the btfs when bpf_object is freed in
> this commit. And I'm trying to offer a way to early free the btfs
> by the users manual to reduce the memory usage. Or, the
> btfs that we opened will keep existing until we close the
> bpf_object.
>
> This is optional, I can remove it if you prefer.
Let's not extend libbpf api unless we really need to.
bpf_program__attach_trace_multi_opts() and
*skel*__attach() can probably free them.
I don't see a use case where you'd want to keep them afterwards.
WARNING: multiple messages have this Message-ID (diff)
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: 梦龙董 <dongmenglong.8@bytedance.com>
Cc: Andrii Nakryiko <andrii@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <martin.lau@linux.dev>,
Eddy Z <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
"David S. Miller" <davem@davemloft.net>,
David Ahern <dsahern@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
X86 ML <x86@kernel.org>, Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Quentin Monnet <quentin@isovalent.com>,
bpf <bpf@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
linux-s390 <linux-s390@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
linux-trace-kernel@vger.kernel.org,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [External] Re: [PATCH bpf-next v2 7/9] libbpf: don't free btf if program of multi-link tracing existing
Date: Mon, 11 Mar 2024 19:13:05 -0700 [thread overview]
Message-ID: <CAADnVQKsrLB-2bD53R4ZdzUVdx1aqkgom1rzGCGKK0M3Uc+csQ@mail.gmail.com> (raw)
In-Reply-To: <CALz3k9iabeOwHSrPb9mkfCuOebanh3+bAfi7xh3kBBN0DzHC3A@mail.gmail.com>
On Mon, Mar 11, 2024 at 7:05 PM 梦龙董 <dongmenglong.8@bytedance.com> wrote:
>
> > >
> > > +LIBBPF_API void bpf_object__free_btfs(struct bpf_object *obj);
> > > +
> >
> > It shouldn't be exported.
> > libbpf should clean it up when bpf_object is freed.
>
> Yes, libbpf will clean up the btfs when bpf_object is freed in
> this commit. And I'm trying to offer a way to early free the btfs
> by the users manual to reduce the memory usage. Or, the
> btfs that we opened will keep existing until we close the
> bpf_object.
>
> This is optional, I can remove it if you prefer.
Let's not extend libbpf api unless we really need to.
bpf_program__attach_trace_multi_opts() and
*skel*__attach() can probably free them.
I don't see a use case where you'd want to keep them afterwards.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: 梦龙董 <dongmenglong.8@bytedance.com>
Cc: Andrii Nakryiko <andrii@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <martin.lau@linux.dev>,
Eddy Z <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
"David S. Miller" <davem@davemloft.net>,
David Ahern <dsahern@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
X86 ML <x86@kernel.org>, Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Quentin Monnet <quentin@isovalent.com>,
bpf <bpf@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
linux-s390 <linux-s390@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
linux-trace-kernel@vger.kernel.org,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [External] Re: [PATCH bpf-next v2 7/9] libbpf: don't free btf if program of multi-link tracing existing
Date: Mon, 11 Mar 2024 19:13:05 -0700 [thread overview]
Message-ID: <CAADnVQKsrLB-2bD53R4ZdzUVdx1aqkgom1rzGCGKK0M3Uc+csQ@mail.gmail.com> (raw)
In-Reply-To: <CALz3k9iabeOwHSrPb9mkfCuOebanh3+bAfi7xh3kBBN0DzHC3A@mail.gmail.com>
On Mon, Mar 11, 2024 at 7:05 PM 梦龙董 <dongmenglong.8@bytedance.com> wrote:
>
> > >
> > > +LIBBPF_API void bpf_object__free_btfs(struct bpf_object *obj);
> > > +
> >
> > It shouldn't be exported.
> > libbpf should clean it up when bpf_object is freed.
>
> Yes, libbpf will clean up the btfs when bpf_object is freed in
> this commit. And I'm trying to offer a way to early free the btfs
> by the users manual to reduce the memory usage. Or, the
> btfs that we opened will keep existing until we close the
> bpf_object.
>
> This is optional, I can remove it if you prefer.
Let's not extend libbpf api unless we really need to.
bpf_program__attach_trace_multi_opts() and
*skel*__attach() can probably free them.
I don't see a use case where you'd want to keep them afterwards.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-03-12 2:13 UTC|newest]
Thread overview: 161+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-11 9:35 [PATCH bpf-next v2 0/9] bpf: make tracing program support multi-link Menglong Dong
2024-03-11 9:35 ` Menglong Dong
2024-03-11 9:35 ` Menglong Dong
2024-03-11 9:35 ` [PATCH bpf-next v2 1/9] bpf: tracing: add support to record and check the accessed args Menglong Dong
2024-03-11 9:35 ` Menglong Dong
2024-03-11 9:35 ` Menglong Dong
2024-03-12 1:46 ` Alexei Starovoitov
2024-03-12 1:46 ` Alexei Starovoitov
2024-03-12 1:46 ` Alexei Starovoitov
2024-03-12 2:01 ` [External] " 梦龙董
2024-03-12 2:01 ` 梦龙董
2024-03-12 2:01 ` 梦龙董
2024-03-12 2:09 ` Alexei Starovoitov
2024-03-12 2:09 ` Alexei Starovoitov
2024-03-12 2:09 ` Alexei Starovoitov
2024-03-12 2:42 ` 梦龙董
2024-03-12 2:42 ` 梦龙董
2024-03-12 2:42 ` 梦龙董
2024-03-12 2:49 ` 梦龙董
2024-03-12 2:49 ` 梦龙董
2024-03-12 2:49 ` 梦龙董
2024-03-12 16:42 ` Alexei Starovoitov
2024-03-12 16:42 ` Alexei Starovoitov
2024-03-12 16:42 ` Alexei Starovoitov
2024-03-13 1:53 ` 梦龙董
2024-03-13 1:53 ` 梦龙董
2024-03-13 1:53 ` 梦龙董
2024-03-14 0:25 ` Alexei Starovoitov
2024-03-14 0:25 ` Alexei Starovoitov
2024-03-14 0:25 ` Alexei Starovoitov
2024-03-14 6:27 ` Jiri Olsa
2024-03-14 6:27 ` Jiri Olsa
2024-03-14 6:27 ` Jiri Olsa
2024-03-15 8:17 ` 梦龙董
2024-03-15 8:17 ` 梦龙董
2024-03-15 8:17 ` 梦龙董
2024-03-15 8:00 ` 梦龙董
2024-03-15 8:00 ` 梦龙董
2024-03-15 8:00 ` 梦龙董
2024-03-28 14:43 ` 梦龙董
2024-03-28 14:43 ` 梦龙董
2024-03-28 14:43 ` 梦龙董
2024-03-28 15:13 ` Steven Rostedt
2024-03-28 15:13 ` Steven Rostedt
2024-03-28 15:13 ` Steven Rostedt
2024-03-28 23:17 ` Alexei Starovoitov
2024-03-28 23:17 ` Alexei Starovoitov
2024-03-28 23:17 ` Alexei Starovoitov
2024-03-30 3:36 ` 梦龙董
2024-03-30 3:36 ` 梦龙董
2024-03-30 3:36 ` 梦龙董
2024-03-29 23:28 ` Andrii Nakryiko
2024-03-29 23:28 ` Andrii Nakryiko
2024-03-29 23:28 ` Andrii Nakryiko
2024-03-29 23:28 ` Andrii Nakryiko
2024-03-29 23:28 ` Andrii Nakryiko
2024-03-29 23:28 ` Andrii Nakryiko
2024-03-29 23:28 ` Andrii Nakryiko
2024-03-29 23:28 ` Andrii Nakryiko
2024-03-29 23:28 ` Andrii Nakryiko
2024-03-30 4:16 ` 梦龙董
2024-03-30 4:16 ` 梦龙董
2024-03-30 4:16 ` 梦龙董
2024-03-30 12:27 ` Steven Rostedt
2024-03-30 12:27 ` Steven Rostedt
2024-03-30 12:27 ` Steven Rostedt
2024-03-30 17:52 ` Jiri Olsa
2024-03-30 17:52 ` Jiri Olsa
2024-03-30 17:52 ` Jiri Olsa
2024-03-31 2:34 ` Andrii Nakryiko
2024-03-31 2:34 ` Andrii Nakryiko
2024-03-31 2:34 ` Andrii Nakryiko
2024-03-31 2:34 ` Andrii Nakryiko
2024-03-31 2:34 ` Andrii Nakryiko
2024-03-31 2:34 ` Andrii Nakryiko
2024-03-31 2:34 ` Andrii Nakryiko
2024-03-31 2:34 ` Andrii Nakryiko
2024-03-30 3:18 ` 梦龙董
2024-03-30 3:18 ` 梦龙董
2024-03-30 3:18 ` 梦龙董
2024-03-30 19:37 ` Steven Rostedt
2024-03-30 19:37 ` Steven Rostedt
2024-03-30 19:37 ` Steven Rostedt
2024-04-01 2:28 ` 梦龙董
2024-04-01 2:28 ` 梦龙董
2024-04-01 2:28 ` 梦龙董
2024-04-01 15:59 ` Steven Rostedt
2024-04-01 15:59 ` Steven Rostedt
2024-04-01 15:59 ` Steven Rostedt
2024-03-11 9:35 ` [PATCH bpf-next v2 2/9] bpf: refactor the modules_array to ptr_array Menglong Dong
2024-03-11 9:35 ` Menglong Dong
2024-03-11 9:35 ` Menglong Dong
2024-03-12 1:48 ` Alexei Starovoitov
2024-03-12 1:48 ` Alexei Starovoitov
2024-03-12 1:48 ` Alexei Starovoitov
2024-03-12 1:53 ` [External] " 梦龙董
2024-03-12 1:53 ` 梦龙董
2024-03-12 1:53 ` 梦龙董
2024-03-11 9:35 ` [PATCH bpf-next v2 3/9] bpf: trampoline: introduce struct bpf_tramp_link_conn Menglong Dong
2024-03-11 9:35 ` Menglong Dong
2024-03-11 9:35 ` Menglong Dong
2024-03-11 9:35 ` [PATCH bpf-next v2 4/9] bpf: trampoline: introduce bpf_tramp_multi_link Menglong Dong
2024-03-11 9:35 ` Menglong Dong
2024-03-11 9:35 ` Menglong Dong
2024-03-11 9:35 ` [PATCH bpf-next v2 5/9] bpf: verifier: add btf to the function args of bpf_check_attach_target Menglong Dong
2024-03-11 9:35 ` Menglong Dong
2024-03-11 9:35 ` Menglong Dong
2024-03-12 1:51 ` Alexei Starovoitov
2024-03-12 1:51 ` Alexei Starovoitov
2024-03-12 1:51 ` Alexei Starovoitov
2024-03-12 3:13 ` [External] " 梦龙董
2024-03-12 3:13 ` 梦龙董
2024-03-12 3:13 ` 梦龙董
2024-03-11 9:35 ` [PATCH bpf-next v2 6/9] bpf: tracing: add multi-link support Menglong Dong
2024-03-11 9:35 ` Menglong Dong
2024-03-11 9:35 ` Menglong Dong
2024-03-11 18:59 ` kernel test robot
2024-03-11 18:59 ` kernel test robot
2024-03-11 18:59 ` kernel test robot
2024-03-11 21:36 ` kernel test robot
2024-03-11 21:36 ` kernel test robot
2024-03-11 21:36 ` kernel test robot
2024-03-11 9:35 ` [PATCH bpf-next v2 7/9] libbpf: don't free btf if program of multi-link tracing existing Menglong Dong
2024-03-11 9:35 ` Menglong Dong
2024-03-11 9:35 ` Menglong Dong
2024-03-12 1:55 ` Alexei Starovoitov
2024-03-12 1:55 ` Alexei Starovoitov
2024-03-12 1:55 ` Alexei Starovoitov
2024-03-12 2:05 ` [External] " 梦龙董
2024-03-12 2:05 ` 梦龙董
2024-03-12 2:05 ` 梦龙董
2024-03-12 2:13 ` Alexei Starovoitov [this message]
2024-03-12 2:13 ` Alexei Starovoitov
2024-03-12 2:13 ` Alexei Starovoitov
2024-03-12 2:56 ` 梦龙董
2024-03-12 2:56 ` 梦龙董
2024-03-12 2:56 ` 梦龙董
2024-03-11 9:35 ` [PATCH bpf-next v2 8/9] libbpf: add support for the multi-link of tracing Menglong Dong
2024-03-11 9:35 ` Menglong Dong
2024-03-11 9:35 ` Menglong Dong
2024-03-11 15:29 ` Quentin Monnet
2024-03-11 15:29 ` Quentin Monnet
2024-03-11 15:29 ` Quentin Monnet
2024-03-12 1:43 ` [External] " 梦龙董
2024-03-12 1:43 ` 梦龙董
2024-03-12 1:43 ` 梦龙董
2024-03-12 1:56 ` Alexei Starovoitov
2024-03-12 1:56 ` Alexei Starovoitov
2024-03-12 1:56 ` Alexei Starovoitov
2024-03-12 2:44 ` [External] " 梦龙董
2024-03-12 2:44 ` 梦龙董
2024-03-12 2:44 ` 梦龙董
2024-03-12 16:11 ` Alexei Starovoitov
2024-03-12 16:11 ` Alexei Starovoitov
2024-03-12 16:11 ` Alexei Starovoitov
2024-03-13 1:14 ` 梦龙董
2024-03-13 1:14 ` 梦龙董
2024-03-13 1:14 ` 梦龙董
2024-03-11 9:35 ` [PATCH bpf-next v2 9/9] selftests/bpf: add testcases for " Menglong Dong
2024-03-11 9:35 ` Menglong Dong
2024-03-11 9:35 ` Menglong Dong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAADnVQKsrLB-2bD53R4ZdzUVdx1aqkgom1rzGCGKK0M3Uc+csQ@mail.gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=agordeev@linux.ibm.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=borntraeger@linux.ibm.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=dongmenglong.8@bytedance.com \
--cc=dsahern@kernel.org \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mathieu.desnoyers@efficios.com \
--cc=netdev@vger.kernel.org \
--cc=quentin@isovalent.com \
--cc=rostedt@goodmis.org \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=svens@linux.ibm.com \
--cc=x86@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.