| Message ID | 20230516123926.57623-3-laoar.shao@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | BPF |
| Headers | show |
| Series | bpf: Show target_{obj,btf}_id for tracing link | expand |
2023-05-16 12:39 UTC+0000 ~ Yafang Shao <laoar.shao@gmail.com> > The target_btf_id can help us understand which kernel function is > linked by a tracing prog. The target_btf_id and target_obj_id have > already been exposed to userspace, so we just need to show them. > > The result as follows, > > $ tools/bpf/bpftool/bpftool link show > 2: tracing prog 13 > prog_type tracing attach_type trace_fentry > target_obj_id 1 target_btf_id 13964 > pids trace(10673) > > $ tools/bpf/bpftool/bpftool link show -j > [{"id":2,"type":"tracing","prog_id":13,"prog_type":"tracing","attach_type":"trace_fentry","target_obj_id":1,"target_btf_id":13964,"pids":[{"pid":10673,"comm":"trace"}]}] > > Signed-off-by: Yafang Shao <laoar.shao@gmail.com> > Acked-by: Song Liu <song@kernel.org> > --- > tools/bpf/bpftool/link.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/tools/bpf/bpftool/link.c b/tools/bpf/bpftool/link.c > index 243b74e..cfe896f 100644 > --- a/tools/bpf/bpftool/link.c > +++ b/tools/bpf/bpftool/link.c > @@ -195,6 +195,8 @@ static int show_link_close_json(int fd, struct bpf_link_info *info) > > show_link_attach_type_json(info->tracing.attach_type, > json_wtr); > + jsonw_uint_field(json_wtr, "target_obj_id", info->tracing.target_obj_id); > + jsonw_uint_field(json_wtr, "target_btf_id", info->tracing.target_btf_id); > break; > case BPF_LINK_TYPE_CGROUP: > jsonw_lluint_field(json_wtr, "cgroup_id", > @@ -375,6 +377,8 @@ static int show_link_close_plain(int fd, struct bpf_link_info *info) > printf("\n\tprog_type %u ", prog_info.type); > > show_link_attach_type_plain(info->tracing.attach_type); > + printf("\n\ttarget_obj_id %u target_btf_id %u ", > + info->tracing.target_obj_id, info->tracing.target_btf_id); Older kernels won't share this info, so maybe we can skip this printf() in plain output if the target object and BTF ids are 0? > break; > case BPF_LINK_TYPE_CGROUP: > printf("\n\tcgroup_id %zu ", (size_t)info->cgroup.cgroup_id);
On Tue, May 16, 2023 at 9:01 PM Quentin Monnet <quentin@isovalent.com> wrote: > > 2023-05-16 12:39 UTC+0000 ~ Yafang Shao <laoar.shao@gmail.com> > > The target_btf_id can help us understand which kernel function is > > linked by a tracing prog. The target_btf_id and target_obj_id have > > already been exposed to userspace, so we just need to show them. > > > > The result as follows, > > > > $ tools/bpf/bpftool/bpftool link show > > 2: tracing prog 13 > > prog_type tracing attach_type trace_fentry > > target_obj_id 1 target_btf_id 13964 > > pids trace(10673) > > > > $ tools/bpf/bpftool/bpftool link show -j > > [{"id":2,"type":"tracing","prog_id":13,"prog_type":"tracing","attach_type":"trace_fentry","target_obj_id":1,"target_btf_id":13964,"pids":[{"pid":10673,"comm":"trace"}]}] > > > > Signed-off-by: Yafang Shao <laoar.shao@gmail.com> > > Acked-by: Song Liu <song@kernel.org> > > --- > > tools/bpf/bpftool/link.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/tools/bpf/bpftool/link.c b/tools/bpf/bpftool/link.c > > index 243b74e..cfe896f 100644 > > --- a/tools/bpf/bpftool/link.c > > +++ b/tools/bpf/bpftool/link.c > > @@ -195,6 +195,8 @@ static int show_link_close_json(int fd, struct bpf_link_info *info) > > > > show_link_attach_type_json(info->tracing.attach_type, > > json_wtr); > > + jsonw_uint_field(json_wtr, "target_obj_id", info->tracing.target_obj_id); > > + jsonw_uint_field(json_wtr, "target_btf_id", info->tracing.target_btf_id); > > break; > > case BPF_LINK_TYPE_CGROUP: > > jsonw_lluint_field(json_wtr, "cgroup_id", > > @@ -375,6 +377,8 @@ static int show_link_close_plain(int fd, struct bpf_link_info *info) > > printf("\n\tprog_type %u ", prog_info.type); > > > > show_link_attach_type_plain(info->tracing.attach_type); > > + printf("\n\ttarget_obj_id %u target_btf_id %u ", > > + info->tracing.target_obj_id, info->tracing.target_btf_id); > > Older kernels won't share this info, so maybe we can skip this printf() > in plain output if the target object and BTF ids are 0? > Good suggestion. Will change it in the next version. BTW, shouldn't we skip it in the json output as well ?
2023-05-16 21:09 UTC+0800 ~ Yafang Shao <laoar.shao@gmail.com> > On Tue, May 16, 2023 at 9:01 PM Quentin Monnet <quentin@isovalent.com> wrote: >> >> 2023-05-16 12:39 UTC+0000 ~ Yafang Shao <laoar.shao@gmail.com> >>> The target_btf_id can help us understand which kernel function is >>> linked by a tracing prog. The target_btf_id and target_obj_id have >>> already been exposed to userspace, so we just need to show them. >>> >>> The result as follows, >>> >>> $ tools/bpf/bpftool/bpftool link show >>> 2: tracing prog 13 >>> prog_type tracing attach_type trace_fentry >>> target_obj_id 1 target_btf_id 13964 >>> pids trace(10673) >>> >>> $ tools/bpf/bpftool/bpftool link show -j >>> [{"id":2,"type":"tracing","prog_id":13,"prog_type":"tracing","attach_type":"trace_fentry","target_obj_id":1,"target_btf_id":13964,"pids":[{"pid":10673,"comm":"trace"}]}] >>> >>> Signed-off-by: Yafang Shao <laoar.shao@gmail.com> >>> Acked-by: Song Liu <song@kernel.org> >>> --- >>> tools/bpf/bpftool/link.c | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/tools/bpf/bpftool/link.c b/tools/bpf/bpftool/link.c >>> index 243b74e..cfe896f 100644 >>> --- a/tools/bpf/bpftool/link.c >>> +++ b/tools/bpf/bpftool/link.c >>> @@ -195,6 +195,8 @@ static int show_link_close_json(int fd, struct bpf_link_info *info) >>> >>> show_link_attach_type_json(info->tracing.attach_type, >>> json_wtr); >>> + jsonw_uint_field(json_wtr, "target_obj_id", info->tracing.target_obj_id); >>> + jsonw_uint_field(json_wtr, "target_btf_id", info->tracing.target_btf_id); >>> break; >>> case BPF_LINK_TYPE_CGROUP: >>> jsonw_lluint_field(json_wtr, "cgroup_id", >>> @@ -375,6 +377,8 @@ static int show_link_close_plain(int fd, struct bpf_link_info *info) >>> printf("\n\tprog_type %u ", prog_info.type); >>> >>> show_link_attach_type_plain(info->tracing.attach_type); >>> + printf("\n\ttarget_obj_id %u target_btf_id %u ", >>> + info->tracing.target_obj_id, info->tracing.target_btf_id); >> >> Older kernels won't share this info, so maybe we can skip this printf() >> in plain output if the target object and BTF ids are 0? >> > > Good suggestion. Will change it in the next version. > BTW, shouldn't we skip it in the json output as well ? I'd keep it in JSON. Plain output is for reading in the console, we want to make it easy for users to find the relevant info. JSON is for machine consumption, it's OK to be more exhaustive and to leave it to the consuming program to decide what's relevant and what's not. Quentin
On Tue, May 16, 2023 at 9:19 PM Quentin Monnet <quentin@isovalent.com> wrote: > > 2023-05-16 21:09 UTC+0800 ~ Yafang Shao <laoar.shao@gmail.com> > > On Tue, May 16, 2023 at 9:01 PM Quentin Monnet <quentin@isovalent.com> wrote: > >> > >> 2023-05-16 12:39 UTC+0000 ~ Yafang Shao <laoar.shao@gmail.com> > >>> The target_btf_id can help us understand which kernel function is > >>> linked by a tracing prog. The target_btf_id and target_obj_id have > >>> already been exposed to userspace, so we just need to show them. > >>> > >>> The result as follows, > >>> > >>> $ tools/bpf/bpftool/bpftool link show > >>> 2: tracing prog 13 > >>> prog_type tracing attach_type trace_fentry > >>> target_obj_id 1 target_btf_id 13964 > >>> pids trace(10673) > >>> > >>> $ tools/bpf/bpftool/bpftool link show -j > >>> [{"id":2,"type":"tracing","prog_id":13,"prog_type":"tracing","attach_type":"trace_fentry","target_obj_id":1,"target_btf_id":13964,"pids":[{"pid":10673,"comm":"trace"}]}] > >>> > >>> Signed-off-by: Yafang Shao <laoar.shao@gmail.com> > >>> Acked-by: Song Liu <song@kernel.org> > >>> --- > >>> tools/bpf/bpftool/link.c | 4 ++++ > >>> 1 file changed, 4 insertions(+) > >>> > >>> diff --git a/tools/bpf/bpftool/link.c b/tools/bpf/bpftool/link.c > >>> index 243b74e..cfe896f 100644 > >>> --- a/tools/bpf/bpftool/link.c > >>> +++ b/tools/bpf/bpftool/link.c > >>> @@ -195,6 +195,8 @@ static int show_link_close_json(int fd, struct bpf_link_info *info) > >>> > >>> show_link_attach_type_json(info->tracing.attach_type, > >>> json_wtr); > >>> + jsonw_uint_field(json_wtr, "target_obj_id", info->tracing.target_obj_id); > >>> + jsonw_uint_field(json_wtr, "target_btf_id", info->tracing.target_btf_id); > >>> break; > >>> case BPF_LINK_TYPE_CGROUP: > >>> jsonw_lluint_field(json_wtr, "cgroup_id", > >>> @@ -375,6 +377,8 @@ static int show_link_close_plain(int fd, struct bpf_link_info *info) > >>> printf("\n\tprog_type %u ", prog_info.type); > >>> > >>> show_link_attach_type_plain(info->tracing.attach_type); > >>> + printf("\n\ttarget_obj_id %u target_btf_id %u ", > >>> + info->tracing.target_obj_id, info->tracing.target_btf_id); > >> > >> Older kernels won't share this info, so maybe we can skip this printf() > >> in plain output if the target object and BTF ids are 0? > >> > > > > Good suggestion. Will change it in the next version. > > BTW, shouldn't we skip it in the json output as well ? > > I'd keep it in JSON. Plain output is for reading in the console, we want > to make it easy for users to find the relevant info. JSON is for machine > consumption, it's OK to be more exhaustive and to leave it to the > consuming program to decide what's relevant and what's not. > Got it. Thanks for the explanation.
diff --git a/tools/bpf/bpftool/link.c b/tools/bpf/bpftool/link.c index 243b74e..cfe896f 100644 --- a/tools/bpf/bpftool/link.c +++ b/tools/bpf/bpftool/link.c @@ -195,6 +195,8 @@ static int show_link_close_json(int fd, struct bpf_link_info *info) show_link_attach_type_json(info->tracing.attach_type, json_wtr); + jsonw_uint_field(json_wtr, "target_obj_id", info->tracing.target_obj_id); + jsonw_uint_field(json_wtr, "target_btf_id", info->tracing.target_btf_id); break; case BPF_LINK_TYPE_CGROUP: jsonw_lluint_field(json_wtr, "cgroup_id", @@ -375,6 +377,8 @@ static int show_link_close_plain(int fd, struct bpf_link_info *info) printf("\n\tprog_type %u ", prog_info.type); show_link_attach_type_plain(info->tracing.attach_type); + printf("\n\ttarget_obj_id %u target_btf_id %u ", + info->tracing.target_obj_id, info->tracing.target_btf_id); break; case BPF_LINK_TYPE_CGROUP: printf("\n\tcgroup_id %zu ", (size_t)info->cgroup.cgroup_id);
The target_btf_id can help us understand which kernel function is linked by a tracing prog. The target_btf_id and target_obj_id have already been exposed to userspace, so we just need to show them. The result as follows, $ tools/bpf/bpftool/bpftool link show 2: tracing prog 13 prog_type tracing attach_type trace_fentry target_obj_id 1 target_btf_id 13964 pids trace(10673) $ tools/bpf/bpftool/bpftool link show -j [{"id":2,"type":"tracing","prog_id":13,"prog_type":"tracing","attach_type":"trace_fentry","target_obj_id":1,"target_btf_id":13964,"pids":[{"pid":10673,"comm":"trace"}]}] Signed-off-by: Yafang Shao <laoar.shao@gmail.com> Acked-by: Song Liu <song@kernel.org> --- tools/bpf/bpftool/link.c | 4 ++++ 1 file changed, 4 insertions(+)