2020-04-29 08:16:12 +08:00
|
|
|
// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
|
|
|
/* Copyright (C) 2020 Facebook */
|
|
|
|
|
|
|
|
#include <errno.h>
|
2022-01-07 23:26:20 +08:00
|
|
|
#include <linux/err.h>
|
2023-04-22 01:02:58 +08:00
|
|
|
#include <linux/netfilter.h>
|
|
|
|
#include <linux/netfilter_arp.h>
|
2020-04-29 08:16:12 +08:00
|
|
|
#include <net/if.h>
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
|
|
|
|
#include <bpf/bpf.h>
|
bpftool: Switch to libbpf's hashmap for pinned paths of BPF objects
In order to show pinned paths for BPF programs, maps, or links when
listing them with the "-f" option, bpftool creates hash maps to store
all relevant paths under the bpffs. So far, it would rely on the
kernel implementation (from tools/include/linux/hashtable.h).
We can make bpftool rely on libbpf's implementation instead. The
motivation is to make bpftool less dependent of kernel headers, to ease
the path to a potential out-of-tree mirror, like libbpf has.
This commit is the first step of the conversion: the hash maps for
pinned paths for programs, maps, and links are converted to libbpf's
hashmap.{c,h}. Other hash maps used for the PIDs of process holding
references to BPF objects are left unchanged for now. On the build side,
this requires adding a dependency to a second header internal to libbpf,
and making it a dependency for the bootstrap bpftool version as well.
The rest of the changes are a rather straightforward conversion.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211023205154.6710-4-quentin@isovalent.com
2021-10-24 04:51:52 +08:00
|
|
|
#include <bpf/hashmap.h>
|
2020-04-29 08:16:12 +08:00
|
|
|
|
|
|
|
#include "json_writer.h"
|
|
|
|
#include "main.h"
|
|
|
|
|
bpftool: Switch to libbpf's hashmap for pinned paths of BPF objects
In order to show pinned paths for BPF programs, maps, or links when
listing them with the "-f" option, bpftool creates hash maps to store
all relevant paths under the bpffs. So far, it would rely on the
kernel implementation (from tools/include/linux/hashtable.h).
We can make bpftool rely on libbpf's implementation instead. The
motivation is to make bpftool less dependent of kernel headers, to ease
the path to a potential out-of-tree mirror, like libbpf has.
This commit is the first step of the conversion: the hash maps for
pinned paths for programs, maps, and links are converted to libbpf's
hashmap.{c,h}. Other hash maps used for the PIDs of process holding
references to BPF objects are left unchanged for now. On the build side,
this requires adding a dependency to a second header internal to libbpf,
and making it a dependency for the bootstrap bpftool version as well.
The rest of the changes are a rather straightforward conversion.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211023205154.6710-4-quentin@isovalent.com
2021-10-24 04:51:52 +08:00
|
|
|
static struct hashmap *link_table;
|
2021-10-24 04:51:51 +08:00
|
|
|
|
2020-04-29 08:16:12 +08:00
|
|
|
static int link_parse_fd(int *argc, char ***argv)
|
|
|
|
{
|
2020-08-01 02:28:29 +08:00
|
|
|
int fd;
|
|
|
|
|
2020-04-29 08:16:12 +08:00
|
|
|
if (is_prefix(**argv, "id")) {
|
|
|
|
unsigned int id;
|
|
|
|
char *endptr;
|
|
|
|
|
|
|
|
NEXT_ARGP();
|
|
|
|
|
|
|
|
id = strtoul(**argv, &endptr, 0);
|
|
|
|
if (*endptr) {
|
|
|
|
p_err("can't parse %s as ID", **argv);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
NEXT_ARGP();
|
|
|
|
|
2020-08-01 02:28:29 +08:00
|
|
|
fd = bpf_link_get_fd_by_id(id);
|
|
|
|
if (fd < 0)
|
|
|
|
p_err("failed to get link with ID %d: %s", id, strerror(errno));
|
|
|
|
return fd;
|
2020-04-29 08:16:12 +08:00
|
|
|
} else if (is_prefix(**argv, "pinned")) {
|
|
|
|
char *path;
|
|
|
|
|
|
|
|
NEXT_ARGP();
|
|
|
|
|
|
|
|
path = **argv;
|
|
|
|
NEXT_ARGP();
|
|
|
|
|
|
|
|
return open_obj_pinned_any(path, BPF_OBJ_LINK);
|
|
|
|
}
|
|
|
|
|
|
|
|
p_err("expected 'id' or 'pinned', got: '%s'?", **argv);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
show_link_header_json(struct bpf_link_info *info, json_writer_t *wtr)
|
|
|
|
{
|
2022-05-24 07:04:28 +08:00
|
|
|
const char *link_type_str;
|
|
|
|
|
2020-04-29 08:16:12 +08:00
|
|
|
jsonw_uint_field(wtr, "id", info->id);
|
2022-05-24 07:04:28 +08:00
|
|
|
link_type_str = libbpf_bpf_link_type_str(info->type);
|
|
|
|
if (link_type_str)
|
|
|
|
jsonw_string_field(wtr, "type", link_type_str);
|
2020-04-29 08:16:12 +08:00
|
|
|
else
|
|
|
|
jsonw_uint_field(wtr, "type", info->type);
|
|
|
|
|
|
|
|
jsonw_uint_field(json_wtr, "prog_id", info->prog_id);
|
|
|
|
}
|
|
|
|
|
2020-05-31 16:28:41 +08:00
|
|
|
static void show_link_attach_type_json(__u32 attach_type, json_writer_t *wtr)
|
|
|
|
{
|
bpftool: Use libbpf_bpf_attach_type_str
This change switches bpftool over to using the recently introduced
libbpf_bpf_attach_type_str function instead of maintaining its own
string representation for the bpf_attach_type enum.
Note that contrary to other enum types, the variant names that bpftool
maps bpf_attach_type to do not adhere a simple to follow rule. With
bpf_prog_type, for example, the textual representation can easily be
inferred by stripping the BPF_PROG_TYPE_ prefix and lowercasing the
remaining string. bpf_attach_type violates this rule for various
variants.
We decided to fix up this deficiency with this change, meaning that
bpftool uses the same textual representations as libbpf. Supporting
tests, completion scripts, and man pages have been adjusted accordingly.
However, we did add support for accepting (the now undocumented)
original attach type names when they are provided by users.
For the test (test_bpftool_synctypes.py), I have removed the enum
representation checks, because we no longer mirror the various enum
variant names in bpftool source code. For the man page, help text, and
completion script checks we are now using enum definitions from
uapi/linux/bpf.h as the source of truth directly.
Signed-off-by: Daniel Müller <deso@posteo.net>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/20220523230428.3077108-10-deso@posteo.net
2022-05-24 07:04:25 +08:00
|
|
|
const char *attach_type_str;
|
|
|
|
|
|
|
|
attach_type_str = libbpf_bpf_attach_type_str(attach_type);
|
|
|
|
if (attach_type_str)
|
|
|
|
jsonw_string_field(wtr, "attach_type", attach_type_str);
|
2020-05-31 16:28:41 +08:00
|
|
|
else
|
|
|
|
jsonw_uint_field(wtr, "attach_type", attach_type);
|
|
|
|
}
|
|
|
|
|
bpftool: Implement link_query for bpf iterators
The link query for bpf iterators is implemented.
Besides being shown to the user what bpf iterator
the link represents, the target_name is also used
to filter out what additional information should be
printed out, e.g., whether map_id should be shown or not.
The following is an example of bpf_iter link dump,
plain output or pretty output.
$ bpftool link show
11: iter prog 59 target_name task
pids test_progs(1749)
34: iter prog 173 target_name bpf_map_elem map_id 127
pids test_progs_1(1753)
$ bpftool -p link show
[{
"id": 11,
"type": "iter",
"prog_id": 59,
"target_name": "task",
"pids": [{
"pid": 1749,
"comm": "test_progs"
}
]
},{
"id": 34,
"type": "iter",
"prog_id": 173,
"target_name": "bpf_map_elem",
"map_id": 127,
"pids": [{
"pid": 1753,
"comm": "test_progs_1"
}
]
}
]
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200821184420.574430-1-yhs@fb.com
2020-08-22 02:44:20 +08:00
|
|
|
static bool is_iter_map_target(const char *target_name)
|
|
|
|
{
|
|
|
|
return strcmp(target_name, "bpf_map_elem") == 0 ||
|
|
|
|
strcmp(target_name, "bpf_sk_storage_map") == 0;
|
|
|
|
}
|
|
|
|
|
bpftool: Add support for querying cgroup_iter link
Support dumping info of a cgroup_iter link. This includes
showing the cgroup's id and the order for walking the cgroup
hierarchy. Example output is as follows:
> bpftool link show
1: iter prog 2 target_name bpf_map
2: iter prog 3 target_name bpf_prog
3: iter prog 12 target_name cgroup cgroup_id 72 order self_only
> bpftool -p link show
[{
"id": 1,
"type": "iter",
"prog_id": 2,
"target_name": "bpf_map"
},{
"id": 2,
"type": "iter",
"prog_id": 3,
"target_name": "bpf_prog"
},{
"id": 3,
"type": "iter",
"prog_id": 12,
"target_name": "cgroup",
"cgroup_id": 72,
"order": "self_only"
}
]
Signed-off-by: Hao Luo <haoluo@google.com>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Acked-by: Yonghong Song <yhs@fb.com>
Link: https://lore.kernel.org/r/20220829231828.1016835-1-haoluo@google.com
Signed-off-by: Martin KaFai Lau <martin.lau@linux.dev>
2022-08-30 07:18:28 +08:00
|
|
|
static bool is_iter_cgroup_target(const char *target_name)
|
|
|
|
{
|
|
|
|
return strcmp(target_name, "cgroup") == 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const char *cgroup_order_string(__u32 order)
|
|
|
|
{
|
|
|
|
switch (order) {
|
|
|
|
case BPF_CGROUP_ITER_ORDER_UNSPEC:
|
|
|
|
return "order_unspec";
|
|
|
|
case BPF_CGROUP_ITER_SELF_ONLY:
|
|
|
|
return "self_only";
|
|
|
|
case BPF_CGROUP_ITER_DESCENDANTS_PRE:
|
|
|
|
return "descendants_pre";
|
|
|
|
case BPF_CGROUP_ITER_DESCENDANTS_POST:
|
|
|
|
return "descendants_post";
|
|
|
|
case BPF_CGROUP_ITER_ANCESTORS_UP:
|
|
|
|
return "ancestors_up";
|
|
|
|
default: /* won't happen */
|
|
|
|
return "unknown";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-09-27 02:49:57 +08:00
|
|
|
static bool is_iter_task_target(const char *target_name)
|
|
|
|
{
|
|
|
|
return strcmp(target_name, "task") == 0 ||
|
|
|
|
strcmp(target_name, "task_file") == 0 ||
|
|
|
|
strcmp(target_name, "task_vma") == 0;
|
|
|
|
}
|
|
|
|
|
bpftool: Implement link_query for bpf iterators
The link query for bpf iterators is implemented.
Besides being shown to the user what bpf iterator
the link represents, the target_name is also used
to filter out what additional information should be
printed out, e.g., whether map_id should be shown or not.
The following is an example of bpf_iter link dump,
plain output or pretty output.
$ bpftool link show
11: iter prog 59 target_name task
pids test_progs(1749)
34: iter prog 173 target_name bpf_map_elem map_id 127
pids test_progs_1(1753)
$ bpftool -p link show
[{
"id": 11,
"type": "iter",
"prog_id": 59,
"target_name": "task",
"pids": [{
"pid": 1749,
"comm": "test_progs"
}
]
},{
"id": 34,
"type": "iter",
"prog_id": 173,
"target_name": "bpf_map_elem",
"map_id": 127,
"pids": [{
"pid": 1753,
"comm": "test_progs_1"
}
]
}
]
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200821184420.574430-1-yhs@fb.com
2020-08-22 02:44:20 +08:00
|
|
|
static void show_iter_json(struct bpf_link_info *info, json_writer_t *wtr)
|
|
|
|
{
|
|
|
|
const char *target_name = u64_to_ptr(info->iter.target_name);
|
|
|
|
|
|
|
|
jsonw_string_field(wtr, "target_name", target_name);
|
|
|
|
|
|
|
|
if (is_iter_map_target(target_name))
|
|
|
|
jsonw_uint_field(wtr, "map_id", info->iter.map.map_id);
|
2022-09-27 02:49:57 +08:00
|
|
|
else if (is_iter_task_target(target_name)) {
|
|
|
|
if (info->iter.task.tid)
|
|
|
|
jsonw_uint_field(wtr, "tid", info->iter.task.tid);
|
|
|
|
else if (info->iter.task.pid)
|
|
|
|
jsonw_uint_field(wtr, "pid", info->iter.task.pid);
|
|
|
|
}
|
bpftool: Add support for querying cgroup_iter link
Support dumping info of a cgroup_iter link. This includes
showing the cgroup's id and the order for walking the cgroup
hierarchy. Example output is as follows:
> bpftool link show
1: iter prog 2 target_name bpf_map
2: iter prog 3 target_name bpf_prog
3: iter prog 12 target_name cgroup cgroup_id 72 order self_only
> bpftool -p link show
[{
"id": 1,
"type": "iter",
"prog_id": 2,
"target_name": "bpf_map"
},{
"id": 2,
"type": "iter",
"prog_id": 3,
"target_name": "bpf_prog"
},{
"id": 3,
"type": "iter",
"prog_id": 12,
"target_name": "cgroup",
"cgroup_id": 72,
"order": "self_only"
}
]
Signed-off-by: Hao Luo <haoluo@google.com>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Acked-by: Yonghong Song <yhs@fb.com>
Link: https://lore.kernel.org/r/20220829231828.1016835-1-haoluo@google.com
Signed-off-by: Martin KaFai Lau <martin.lau@linux.dev>
2022-08-30 07:18:28 +08:00
|
|
|
|
|
|
|
if (is_iter_cgroup_target(target_name)) {
|
|
|
|
jsonw_lluint_field(wtr, "cgroup_id", info->iter.cgroup.cgroup_id);
|
|
|
|
jsonw_string_field(wtr, "order",
|
|
|
|
cgroup_order_string(info->iter.cgroup.order));
|
|
|
|
}
|
bpftool: Implement link_query for bpf iterators
The link query for bpf iterators is implemented.
Besides being shown to the user what bpf iterator
the link represents, the target_name is also used
to filter out what additional information should be
printed out, e.g., whether map_id should be shown or not.
The following is an example of bpf_iter link dump,
plain output or pretty output.
$ bpftool link show
11: iter prog 59 target_name task
pids test_progs(1749)
34: iter prog 173 target_name bpf_map_elem map_id 127
pids test_progs_1(1753)
$ bpftool -p link show
[{
"id": 11,
"type": "iter",
"prog_id": 59,
"target_name": "task",
"pids": [{
"pid": 1749,
"comm": "test_progs"
}
]
},{
"id": 34,
"type": "iter",
"prog_id": 173,
"target_name": "bpf_map_elem",
"map_id": 127,
"pids": [{
"pid": 1753,
"comm": "test_progs_1"
}
]
}
]
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200821184420.574430-1-yhs@fb.com
2020-08-22 02:44:20 +08:00
|
|
|
}
|
|
|
|
|
2023-04-22 01:02:58 +08:00
|
|
|
void netfilter_dump_json(const struct bpf_link_info *info, json_writer_t *wtr)
|
|
|
|
{
|
|
|
|
jsonw_uint_field(json_wtr, "pf",
|
|
|
|
info->netfilter.pf);
|
|
|
|
jsonw_uint_field(json_wtr, "hook",
|
|
|
|
info->netfilter.hooknum);
|
|
|
|
jsonw_int_field(json_wtr, "prio",
|
|
|
|
info->netfilter.priority);
|
|
|
|
jsonw_uint_field(json_wtr, "flags",
|
|
|
|
info->netfilter.flags);
|
|
|
|
}
|
|
|
|
|
2020-04-29 08:16:12 +08:00
|
|
|
static int get_prog_info(int prog_id, struct bpf_prog_info *info)
|
|
|
|
{
|
|
|
|
__u32 len = sizeof(*info);
|
|
|
|
int err, prog_fd;
|
|
|
|
|
|
|
|
prog_fd = bpf_prog_get_fd_by_id(prog_id);
|
|
|
|
if (prog_fd < 0)
|
|
|
|
return prog_fd;
|
|
|
|
|
|
|
|
memset(info, 0, sizeof(*info));
|
2023-02-15 07:12:16 +08:00
|
|
|
err = bpf_prog_get_info_by_fd(prog_fd, info, &len);
|
2020-04-29 08:16:12 +08:00
|
|
|
if (err)
|
|
|
|
p_err("can't get prog info: %s", strerror(errno));
|
|
|
|
close(prog_fd);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int show_link_close_json(int fd, struct bpf_link_info *info)
|
|
|
|
{
|
|
|
|
struct bpf_prog_info prog_info;
|
2022-05-24 07:04:19 +08:00
|
|
|
const char *prog_type_str;
|
2020-04-29 08:16:12 +08:00
|
|
|
int err;
|
|
|
|
|
|
|
|
jsonw_start_object(json_wtr);
|
|
|
|
|
|
|
|
show_link_header_json(info, json_wtr);
|
|
|
|
|
|
|
|
switch (info->type) {
|
|
|
|
case BPF_LINK_TYPE_RAW_TRACEPOINT:
|
|
|
|
jsonw_string_field(json_wtr, "tp_name",
|
2020-08-14 04:49:37 +08:00
|
|
|
u64_to_ptr(info->raw_tracepoint.tp_name));
|
2020-04-29 08:16:12 +08:00
|
|
|
break;
|
|
|
|
case BPF_LINK_TYPE_TRACING:
|
|
|
|
err = get_prog_info(info->prog_id, &prog_info);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2022-05-24 07:04:19 +08:00
|
|
|
prog_type_str = libbpf_bpf_prog_type_str(prog_info.type);
|
|
|
|
/* libbpf will return NULL for variants unknown to it. */
|
|
|
|
if (prog_type_str)
|
|
|
|
jsonw_string_field(json_wtr, "prog_type", prog_type_str);
|
2020-04-29 08:16:12 +08:00
|
|
|
else
|
2022-05-24 07:04:19 +08:00
|
|
|
jsonw_uint_field(json_wtr, "prog_type", prog_info.type);
|
2020-04-29 08:16:12 +08:00
|
|
|
|
2020-05-31 16:28:41 +08:00
|
|
|
show_link_attach_type_json(info->tracing.attach_type,
|
|
|
|
json_wtr);
|
bpftool: Show target_{obj,btf}_id in tracing link info
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>
Link: https://lore.kernel.org/r/20230517103126.68372-3-laoar.shao@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-05-17 18:31:26 +08:00
|
|
|
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);
|
2020-04-29 08:16:12 +08:00
|
|
|
break;
|
|
|
|
case BPF_LINK_TYPE_CGROUP:
|
|
|
|
jsonw_lluint_field(json_wtr, "cgroup_id",
|
|
|
|
info->cgroup.cgroup_id);
|
2020-05-31 16:28:41 +08:00
|
|
|
show_link_attach_type_json(info->cgroup.attach_type, json_wtr);
|
2020-04-29 08:16:12 +08:00
|
|
|
break;
|
bpftool: Implement link_query for bpf iterators
The link query for bpf iterators is implemented.
Besides being shown to the user what bpf iterator
the link represents, the target_name is also used
to filter out what additional information should be
printed out, e.g., whether map_id should be shown or not.
The following is an example of bpf_iter link dump,
plain output or pretty output.
$ bpftool link show
11: iter prog 59 target_name task
pids test_progs(1749)
34: iter prog 173 target_name bpf_map_elem map_id 127
pids test_progs_1(1753)
$ bpftool -p link show
[{
"id": 11,
"type": "iter",
"prog_id": 59,
"target_name": "task",
"pids": [{
"pid": 1749,
"comm": "test_progs"
}
]
},{
"id": 34,
"type": "iter",
"prog_id": 173,
"target_name": "bpf_map_elem",
"map_id": 127,
"pids": [{
"pid": 1753,
"comm": "test_progs_1"
}
]
}
]
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200821184420.574430-1-yhs@fb.com
2020-08-22 02:44:20 +08:00
|
|
|
case BPF_LINK_TYPE_ITER:
|
|
|
|
show_iter_json(info, json_wtr);
|
|
|
|
break;
|
bpftool: Support link show for netns-attached links
Make `bpf link show` aware of new link type, that is links attached to
netns. When listing netns-attached links, display netns inode number as its
identifier and link attach type.
Sample session:
# readlink /proc/self/ns/net
net:[4026532251]
# bpftool prog show
357: flow_dissector tag a04f5eef06a7f555 gpl
loaded_at 2020-05-30T16:53:51+0200 uid 0
xlated 16B jited 37B memlock 4096B
358: flow_dissector tag a04f5eef06a7f555 gpl
loaded_at 2020-05-30T16:53:51+0200 uid 0
xlated 16B jited 37B memlock 4096B
# bpftool link show
108: netns prog 357
netns_ino 4026532251 attach_type flow_dissector
# bpftool link -jp show
[{
"id": 108,
"type": "netns",
"prog_id": 357,
"netns_ino": 4026532251,
"attach_type": "flow_dissector"
}
]
(... after netns is gone ...)
# bpftool link show
108: netns prog 357
netns_ino 0 attach_type flow_dissector
# bpftool link -jp show
[{
"id": 108,
"type": "netns",
"prog_id": 357,
"netns_ino": 0,
"attach_type": "flow_dissector"
}
]
Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200531082846.2117903-9-jakub@cloudflare.com
2020-05-31 16:28:42 +08:00
|
|
|
case BPF_LINK_TYPE_NETNS:
|
|
|
|
jsonw_uint_field(json_wtr, "netns_ino",
|
|
|
|
info->netns.netns_ino);
|
|
|
|
show_link_attach_type_json(info->netns.attach_type, json_wtr);
|
|
|
|
break;
|
2023-04-22 01:02:58 +08:00
|
|
|
case BPF_LINK_TYPE_NETFILTER:
|
|
|
|
netfilter_dump_json(info, json_wtr);
|
|
|
|
break;
|
2023-04-22 05:41:31 +08:00
|
|
|
case BPF_LINK_TYPE_STRUCT_OPS:
|
|
|
|
jsonw_uint_field(json_wtr, "map_id",
|
|
|
|
info->struct_ops.map_id);
|
|
|
|
break;
|
2020-04-29 08:16:12 +08:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
bpftool: Switch to libbpf's hashmap for pinned paths of BPF objects
In order to show pinned paths for BPF programs, maps, or links when
listing them with the "-f" option, bpftool creates hash maps to store
all relevant paths under the bpffs. So far, it would rely on the
kernel implementation (from tools/include/linux/hashtable.h).
We can make bpftool rely on libbpf's implementation instead. The
motivation is to make bpftool less dependent of kernel headers, to ease
the path to a potential out-of-tree mirror, like libbpf has.
This commit is the first step of the conversion: the hash maps for
pinned paths for programs, maps, and links are converted to libbpf's
hashmap.{c,h}. Other hash maps used for the PIDs of process holding
references to BPF objects are left unchanged for now. On the build side,
this requires adding a dependency to a second header internal to libbpf,
and making it a dependency for the bootstrap bpftool version as well.
The rest of the changes are a rather straightforward conversion.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211023205154.6710-4-quentin@isovalent.com
2021-10-24 04:51:52 +08:00
|
|
|
if (!hashmap__empty(link_table)) {
|
|
|
|
struct hashmap_entry *entry;
|
2020-04-29 08:16:12 +08:00
|
|
|
|
|
|
|
jsonw_name(json_wtr, "pinned");
|
|
|
|
jsonw_start_array(json_wtr);
|
libbpf: Hashmap interface update to allow both long and void* keys/values
An update for libbpf's hashmap interface from void* -> void* to a
polymorphic one, allowing both long and void* keys and values.
This simplifies many use cases in libbpf as hashmaps there are mostly
integer to integer.
Perf copies hashmap implementation from libbpf and has to be
updated as well.
Changes to libbpf, selftests/bpf and perf are packed as a single
commit to avoid compilation issues with any future bisect.
Polymorphic interface is acheived by hiding hashmap interface
functions behind auxiliary macros that take care of necessary
type casts, for example:
#define hashmap_cast_ptr(p) \
({ \
_Static_assert((p) == NULL || sizeof(*(p)) == sizeof(long),\
#p " pointee should be a long-sized integer or a pointer"); \
(long *)(p); \
})
bool hashmap_find(const struct hashmap *map, long key, long *value);
#define hashmap__find(map, key, value) \
hashmap_find((map), (long)(key), hashmap_cast_ptr(value))
- hashmap__find macro casts key and value parameters to long
and long* respectively
- hashmap_cast_ptr ensures that value pointer points to a memory
of appropriate size.
This hack was suggested by Andrii Nakryiko in [1].
This is a follow up for [2].
[1] https://lore.kernel.org/bpf/CAEf4BzZ8KFneEJxFAaNCCFPGqp20hSpS2aCj76uRk3-qZUH5xg@mail.gmail.com/
[2] https://lore.kernel.org/bpf/af1facf9-7bc8-8a3d-0db4-7b3f333589a2@meta.com/T/#m65b28f1d6d969fcd318b556db6a3ad499a42607d
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20221109142611.879983-2-eddyz87@gmail.com
2022-11-09 22:26:09 +08:00
|
|
|
hashmap__for_each_key_entry(link_table, entry, info->id)
|
|
|
|
jsonw_string(json_wtr, entry->pvalue);
|
2020-04-29 08:16:12 +08:00
|
|
|
jsonw_end_array(json_wtr);
|
|
|
|
}
|
tools/bpftool: Show info for processes holding BPF map/prog/link/btf FDs
Add bpf_iter-based way to find all the processes that hold open FDs against
BPF object (map, prog, link, btf). bpftool always attempts to discover this,
but will silently give up if kernel doesn't yet support bpf_iter BPF programs.
Process name and PID are emitted for each process (task group).
Sample output for each of 4 BPF objects:
$ sudo ./bpftool prog show
2694: cgroup_device tag 8c42dee26e8cd4c2 gpl
loaded_at 2020-06-16T15:34:32-0700 uid 0
xlated 648B jited 409B memlock 4096B
pids systemd(1)
2907: cgroup_skb name egress tag 9ad187367cf2b9e8 gpl
loaded_at 2020-06-16T18:06:54-0700 uid 0
xlated 48B jited 59B memlock 4096B map_ids 2436
btf_id 1202
pids test_progs(2238417), test_progs(2238445)
$ sudo ./bpftool map show
2436: array name test_cgr.bss flags 0x400
key 4B value 8B max_entries 1 memlock 8192B
btf_id 1202
pids test_progs(2238417), test_progs(2238445)
2445: array name pid_iter.rodata flags 0x480
key 4B value 4B max_entries 1 memlock 8192B
btf_id 1214 frozen
pids bpftool(2239612)
$ sudo ./bpftool link show
61: cgroup prog 2908
cgroup_id 375301 attach_type egress
pids test_progs(2238417), test_progs(2238445)
62: cgroup prog 2908
cgroup_id 375344 attach_type egress
pids test_progs(2238417), test_progs(2238445)
$ sudo ./bpftool btf show
1202: size 1527B prog_ids 2908,2907 map_ids 2436
pids test_progs(2238417), test_progs(2238445)
1242: size 34684B
pids bpftool(2258892)
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/20200619231703.738941-9-andriin@fb.com
2020-06-20 07:17:02 +08:00
|
|
|
|
bpftool: Switch to libbpf's hashmap for PIDs/names references
In order to show PIDs and names for processes holding references to BPF
programs, maps, links, or BTF objects, bpftool creates hash maps to
store all relevant information. This commit is part of a set that
transitions from the kernel's hash map implementation to the one coming
with libbpf.
The motivation is to make bpftool less dependent of kernel headers, to
ease the path to a potential out-of-tree mirror, like libbpf has.
This is the third and final step of the transition, in which we convert
the hash maps used for storing the information about the processes
holding references to BPF objects (programs, maps, links, BTF), and at
last we drop the inclusion of tools/include/linux/hashtable.h.
Note: Checkpatch complains about the use of __weak declarations, and the
missing empty lines after the bunch of empty function declarations when
compiling without the BPF skeletons (none of these were introduced in
this patch). We want to keep things as they are, and the reports should
be safe to ignore.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211023205154.6710-6-quentin@isovalent.com
2021-10-24 04:51:54 +08:00
|
|
|
emit_obj_refs_json(refs_table, info->id, json_wtr);
|
tools/bpftool: Show info for processes holding BPF map/prog/link/btf FDs
Add bpf_iter-based way to find all the processes that hold open FDs against
BPF object (map, prog, link, btf). bpftool always attempts to discover this,
but will silently give up if kernel doesn't yet support bpf_iter BPF programs.
Process name and PID are emitted for each process (task group).
Sample output for each of 4 BPF objects:
$ sudo ./bpftool prog show
2694: cgroup_device tag 8c42dee26e8cd4c2 gpl
loaded_at 2020-06-16T15:34:32-0700 uid 0
xlated 648B jited 409B memlock 4096B
pids systemd(1)
2907: cgroup_skb name egress tag 9ad187367cf2b9e8 gpl
loaded_at 2020-06-16T18:06:54-0700 uid 0
xlated 48B jited 59B memlock 4096B map_ids 2436
btf_id 1202
pids test_progs(2238417), test_progs(2238445)
$ sudo ./bpftool map show
2436: array name test_cgr.bss flags 0x400
key 4B value 8B max_entries 1 memlock 8192B
btf_id 1202
pids test_progs(2238417), test_progs(2238445)
2445: array name pid_iter.rodata flags 0x480
key 4B value 4B max_entries 1 memlock 8192B
btf_id 1214 frozen
pids bpftool(2239612)
$ sudo ./bpftool link show
61: cgroup prog 2908
cgroup_id 375301 attach_type egress
pids test_progs(2238417), test_progs(2238445)
62: cgroup prog 2908
cgroup_id 375344 attach_type egress
pids test_progs(2238417), test_progs(2238445)
$ sudo ./bpftool btf show
1202: size 1527B prog_ids 2908,2907 map_ids 2436
pids test_progs(2238417), test_progs(2238445)
1242: size 34684B
pids bpftool(2258892)
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/20200619231703.738941-9-andriin@fb.com
2020-06-20 07:17:02 +08:00
|
|
|
|
2020-04-29 08:16:12 +08:00
|
|
|
jsonw_end_object(json_wtr);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void show_link_header_plain(struct bpf_link_info *info)
|
|
|
|
{
|
2022-05-24 07:04:28 +08:00
|
|
|
const char *link_type_str;
|
|
|
|
|
2020-04-29 08:16:12 +08:00
|
|
|
printf("%u: ", info->id);
|
2022-05-24 07:04:28 +08:00
|
|
|
link_type_str = libbpf_bpf_link_type_str(info->type);
|
|
|
|
if (link_type_str)
|
|
|
|
printf("%s ", link_type_str);
|
2020-04-29 08:16:12 +08:00
|
|
|
else
|
|
|
|
printf("type %u ", info->type);
|
|
|
|
|
2023-04-22 05:41:31 +08:00
|
|
|
if (info->type == BPF_LINK_TYPE_STRUCT_OPS)
|
|
|
|
printf("map %u ", info->struct_ops.map_id);
|
|
|
|
else
|
|
|
|
printf("prog %u ", info->prog_id);
|
2020-04-29 08:16:12 +08:00
|
|
|
}
|
|
|
|
|
2020-05-31 16:28:41 +08:00
|
|
|
static void show_link_attach_type_plain(__u32 attach_type)
|
|
|
|
{
|
bpftool: Use libbpf_bpf_attach_type_str
This change switches bpftool over to using the recently introduced
libbpf_bpf_attach_type_str function instead of maintaining its own
string representation for the bpf_attach_type enum.
Note that contrary to other enum types, the variant names that bpftool
maps bpf_attach_type to do not adhere a simple to follow rule. With
bpf_prog_type, for example, the textual representation can easily be
inferred by stripping the BPF_PROG_TYPE_ prefix and lowercasing the
remaining string. bpf_attach_type violates this rule for various
variants.
We decided to fix up this deficiency with this change, meaning that
bpftool uses the same textual representations as libbpf. Supporting
tests, completion scripts, and man pages have been adjusted accordingly.
However, we did add support for accepting (the now undocumented)
original attach type names when they are provided by users.
For the test (test_bpftool_synctypes.py), I have removed the enum
representation checks, because we no longer mirror the various enum
variant names in bpftool source code. For the man page, help text, and
completion script checks we are now using enum definitions from
uapi/linux/bpf.h as the source of truth directly.
Signed-off-by: Daniel Müller <deso@posteo.net>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/20220523230428.3077108-10-deso@posteo.net
2022-05-24 07:04:25 +08:00
|
|
|
const char *attach_type_str;
|
|
|
|
|
|
|
|
attach_type_str = libbpf_bpf_attach_type_str(attach_type);
|
|
|
|
if (attach_type_str)
|
|
|
|
printf("attach_type %s ", attach_type_str);
|
2020-05-31 16:28:41 +08:00
|
|
|
else
|
|
|
|
printf("attach_type %u ", attach_type);
|
|
|
|
}
|
|
|
|
|
bpftool: Implement link_query for bpf iterators
The link query for bpf iterators is implemented.
Besides being shown to the user what bpf iterator
the link represents, the target_name is also used
to filter out what additional information should be
printed out, e.g., whether map_id should be shown or not.
The following is an example of bpf_iter link dump,
plain output or pretty output.
$ bpftool link show
11: iter prog 59 target_name task
pids test_progs(1749)
34: iter prog 173 target_name bpf_map_elem map_id 127
pids test_progs_1(1753)
$ bpftool -p link show
[{
"id": 11,
"type": "iter",
"prog_id": 59,
"target_name": "task",
"pids": [{
"pid": 1749,
"comm": "test_progs"
}
]
},{
"id": 34,
"type": "iter",
"prog_id": 173,
"target_name": "bpf_map_elem",
"map_id": 127,
"pids": [{
"pid": 1753,
"comm": "test_progs_1"
}
]
}
]
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200821184420.574430-1-yhs@fb.com
2020-08-22 02:44:20 +08:00
|
|
|
static void show_iter_plain(struct bpf_link_info *info)
|
|
|
|
{
|
|
|
|
const char *target_name = u64_to_ptr(info->iter.target_name);
|
|
|
|
|
|
|
|
printf("target_name %s ", target_name);
|
|
|
|
|
|
|
|
if (is_iter_map_target(target_name))
|
|
|
|
printf("map_id %u ", info->iter.map.map_id);
|
2022-09-27 02:49:57 +08:00
|
|
|
else if (is_iter_task_target(target_name)) {
|
|
|
|
if (info->iter.task.tid)
|
|
|
|
printf("tid %u ", info->iter.task.tid);
|
|
|
|
else if (info->iter.task.pid)
|
|
|
|
printf("pid %u ", info->iter.task.pid);
|
|
|
|
}
|
bpftool: Add support for querying cgroup_iter link
Support dumping info of a cgroup_iter link. This includes
showing the cgroup's id and the order for walking the cgroup
hierarchy. Example output is as follows:
> bpftool link show
1: iter prog 2 target_name bpf_map
2: iter prog 3 target_name bpf_prog
3: iter prog 12 target_name cgroup cgroup_id 72 order self_only
> bpftool -p link show
[{
"id": 1,
"type": "iter",
"prog_id": 2,
"target_name": "bpf_map"
},{
"id": 2,
"type": "iter",
"prog_id": 3,
"target_name": "bpf_prog"
},{
"id": 3,
"type": "iter",
"prog_id": 12,
"target_name": "cgroup",
"cgroup_id": 72,
"order": "self_only"
}
]
Signed-off-by: Hao Luo <haoluo@google.com>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Acked-by: Yonghong Song <yhs@fb.com>
Link: https://lore.kernel.org/r/20220829231828.1016835-1-haoluo@google.com
Signed-off-by: Martin KaFai Lau <martin.lau@linux.dev>
2022-08-30 07:18:28 +08:00
|
|
|
|
|
|
|
if (is_iter_cgroup_target(target_name)) {
|
|
|
|
printf("cgroup_id %llu ", info->iter.cgroup.cgroup_id);
|
|
|
|
printf("order %s ",
|
|
|
|
cgroup_order_string(info->iter.cgroup.order));
|
|
|
|
}
|
bpftool: Implement link_query for bpf iterators
The link query for bpf iterators is implemented.
Besides being shown to the user what bpf iterator
the link represents, the target_name is also used
to filter out what additional information should be
printed out, e.g., whether map_id should be shown or not.
The following is an example of bpf_iter link dump,
plain output or pretty output.
$ bpftool link show
11: iter prog 59 target_name task
pids test_progs(1749)
34: iter prog 173 target_name bpf_map_elem map_id 127
pids test_progs_1(1753)
$ bpftool -p link show
[{
"id": 11,
"type": "iter",
"prog_id": 59,
"target_name": "task",
"pids": [{
"pid": 1749,
"comm": "test_progs"
}
]
},{
"id": 34,
"type": "iter",
"prog_id": 173,
"target_name": "bpf_map_elem",
"map_id": 127,
"pids": [{
"pid": 1753,
"comm": "test_progs_1"
}
]
}
]
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200821184420.574430-1-yhs@fb.com
2020-08-22 02:44:20 +08:00
|
|
|
}
|
|
|
|
|
2023-04-22 01:02:58 +08:00
|
|
|
static const char * const pf2name[] = {
|
|
|
|
[NFPROTO_INET] = "inet",
|
|
|
|
[NFPROTO_IPV4] = "ip",
|
|
|
|
[NFPROTO_ARP] = "arp",
|
|
|
|
[NFPROTO_NETDEV] = "netdev",
|
|
|
|
[NFPROTO_BRIDGE] = "bridge",
|
|
|
|
[NFPROTO_IPV6] = "ip6",
|
|
|
|
};
|
|
|
|
|
|
|
|
static const char * const inethook2name[] = {
|
|
|
|
[NF_INET_PRE_ROUTING] = "prerouting",
|
|
|
|
[NF_INET_LOCAL_IN] = "input",
|
|
|
|
[NF_INET_FORWARD] = "forward",
|
|
|
|
[NF_INET_LOCAL_OUT] = "output",
|
|
|
|
[NF_INET_POST_ROUTING] = "postrouting",
|
|
|
|
};
|
|
|
|
|
|
|
|
static const char * const arphook2name[] = {
|
|
|
|
[NF_ARP_IN] = "input",
|
|
|
|
[NF_ARP_OUT] = "output",
|
|
|
|
};
|
|
|
|
|
|
|
|
void netfilter_dump_plain(const struct bpf_link_info *info)
|
|
|
|
{
|
|
|
|
const char *hookname = NULL, *pfname = NULL;
|
|
|
|
unsigned int hook = info->netfilter.hooknum;
|
|
|
|
unsigned int pf = info->netfilter.pf;
|
|
|
|
|
|
|
|
if (pf < ARRAY_SIZE(pf2name))
|
|
|
|
pfname = pf2name[pf];
|
|
|
|
|
|
|
|
switch (pf) {
|
|
|
|
case NFPROTO_BRIDGE: /* bridge shares numbers with enum nf_inet_hooks */
|
|
|
|
case NFPROTO_IPV4:
|
|
|
|
case NFPROTO_IPV6:
|
|
|
|
case NFPROTO_INET:
|
|
|
|
if (hook < ARRAY_SIZE(inethook2name))
|
|
|
|
hookname = inethook2name[hook];
|
|
|
|
break;
|
|
|
|
case NFPROTO_ARP:
|
|
|
|
if (hook < ARRAY_SIZE(arphook2name))
|
|
|
|
hookname = arphook2name[hook];
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pfname)
|
|
|
|
printf("\n\t%s", pfname);
|
|
|
|
else
|
|
|
|
printf("\n\tpf: %d", pf);
|
|
|
|
|
|
|
|
if (hookname)
|
|
|
|
printf(" %s", hookname);
|
|
|
|
else
|
|
|
|
printf(", hook %u,", hook);
|
|
|
|
|
|
|
|
printf(" prio %d", info->netfilter.priority);
|
|
|
|
|
|
|
|
if (info->netfilter.flags)
|
|
|
|
printf(" flags 0x%x", info->netfilter.flags);
|
|
|
|
}
|
|
|
|
|
2020-04-29 08:16:12 +08:00
|
|
|
static int show_link_close_plain(int fd, struct bpf_link_info *info)
|
|
|
|
{
|
|
|
|
struct bpf_prog_info prog_info;
|
2022-05-24 07:04:19 +08:00
|
|
|
const char *prog_type_str;
|
2020-04-29 08:16:12 +08:00
|
|
|
int err;
|
|
|
|
|
|
|
|
show_link_header_plain(info);
|
|
|
|
|
|
|
|
switch (info->type) {
|
|
|
|
case BPF_LINK_TYPE_RAW_TRACEPOINT:
|
|
|
|
printf("\n\ttp '%s' ",
|
2020-08-14 04:49:37 +08:00
|
|
|
(const char *)u64_to_ptr(info->raw_tracepoint.tp_name));
|
2020-04-29 08:16:12 +08:00
|
|
|
break;
|
|
|
|
case BPF_LINK_TYPE_TRACING:
|
|
|
|
err = get_prog_info(info->prog_id, &prog_info);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2022-05-24 07:04:19 +08:00
|
|
|
prog_type_str = libbpf_bpf_prog_type_str(prog_info.type);
|
|
|
|
/* libbpf will return NULL for variants unknown to it. */
|
|
|
|
if (prog_type_str)
|
|
|
|
printf("\n\tprog_type %s ", prog_type_str);
|
2020-04-29 08:16:12 +08:00
|
|
|
else
|
|
|
|
printf("\n\tprog_type %u ", prog_info.type);
|
|
|
|
|
2020-05-31 16:28:41 +08:00
|
|
|
show_link_attach_type_plain(info->tracing.attach_type);
|
bpftool: Show target_{obj,btf}_id in tracing link info
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>
Link: https://lore.kernel.org/r/20230517103126.68372-3-laoar.shao@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-05-17 18:31:26 +08:00
|
|
|
if (info->tracing.target_obj_id || info->tracing.target_btf_id)
|
|
|
|
printf("\n\ttarget_obj_id %u target_btf_id %u ",
|
|
|
|
info->tracing.target_obj_id,
|
|
|
|
info->tracing.target_btf_id);
|
2020-04-29 08:16:12 +08:00
|
|
|
break;
|
|
|
|
case BPF_LINK_TYPE_CGROUP:
|
|
|
|
printf("\n\tcgroup_id %zu ", (size_t)info->cgroup.cgroup_id);
|
2020-05-31 16:28:41 +08:00
|
|
|
show_link_attach_type_plain(info->cgroup.attach_type);
|
2020-04-29 08:16:12 +08:00
|
|
|
break;
|
bpftool: Implement link_query for bpf iterators
The link query for bpf iterators is implemented.
Besides being shown to the user what bpf iterator
the link represents, the target_name is also used
to filter out what additional information should be
printed out, e.g., whether map_id should be shown or not.
The following is an example of bpf_iter link dump,
plain output or pretty output.
$ bpftool link show
11: iter prog 59 target_name task
pids test_progs(1749)
34: iter prog 173 target_name bpf_map_elem map_id 127
pids test_progs_1(1753)
$ bpftool -p link show
[{
"id": 11,
"type": "iter",
"prog_id": 59,
"target_name": "task",
"pids": [{
"pid": 1749,
"comm": "test_progs"
}
]
},{
"id": 34,
"type": "iter",
"prog_id": 173,
"target_name": "bpf_map_elem",
"map_id": 127,
"pids": [{
"pid": 1753,
"comm": "test_progs_1"
}
]
}
]
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200821184420.574430-1-yhs@fb.com
2020-08-22 02:44:20 +08:00
|
|
|
case BPF_LINK_TYPE_ITER:
|
|
|
|
show_iter_plain(info);
|
|
|
|
break;
|
bpftool: Support link show for netns-attached links
Make `bpf link show` aware of new link type, that is links attached to
netns. When listing netns-attached links, display netns inode number as its
identifier and link attach type.
Sample session:
# readlink /proc/self/ns/net
net:[4026532251]
# bpftool prog show
357: flow_dissector tag a04f5eef06a7f555 gpl
loaded_at 2020-05-30T16:53:51+0200 uid 0
xlated 16B jited 37B memlock 4096B
358: flow_dissector tag a04f5eef06a7f555 gpl
loaded_at 2020-05-30T16:53:51+0200 uid 0
xlated 16B jited 37B memlock 4096B
# bpftool link show
108: netns prog 357
netns_ino 4026532251 attach_type flow_dissector
# bpftool link -jp show
[{
"id": 108,
"type": "netns",
"prog_id": 357,
"netns_ino": 4026532251,
"attach_type": "flow_dissector"
}
]
(... after netns is gone ...)
# bpftool link show
108: netns prog 357
netns_ino 0 attach_type flow_dissector
# bpftool link -jp show
[{
"id": 108,
"type": "netns",
"prog_id": 357,
"netns_ino": 0,
"attach_type": "flow_dissector"
}
]
Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200531082846.2117903-9-jakub@cloudflare.com
2020-05-31 16:28:42 +08:00
|
|
|
case BPF_LINK_TYPE_NETNS:
|
|
|
|
printf("\n\tnetns_ino %u ", info->netns.netns_ino);
|
|
|
|
show_link_attach_type_plain(info->netns.attach_type);
|
|
|
|
break;
|
2023-04-22 01:02:58 +08:00
|
|
|
case BPF_LINK_TYPE_NETFILTER:
|
|
|
|
netfilter_dump_plain(info);
|
|
|
|
break;
|
2020-04-29 08:16:12 +08:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
bpftool: Switch to libbpf's hashmap for pinned paths of BPF objects
In order to show pinned paths for BPF programs, maps, or links when
listing them with the "-f" option, bpftool creates hash maps to store
all relevant paths under the bpffs. So far, it would rely on the
kernel implementation (from tools/include/linux/hashtable.h).
We can make bpftool rely on libbpf's implementation instead. The
motivation is to make bpftool less dependent of kernel headers, to ease
the path to a potential out-of-tree mirror, like libbpf has.
This commit is the first step of the conversion: the hash maps for
pinned paths for programs, maps, and links are converted to libbpf's
hashmap.{c,h}. Other hash maps used for the PIDs of process holding
references to BPF objects are left unchanged for now. On the build side,
this requires adding a dependency to a second header internal to libbpf,
and making it a dependency for the bootstrap bpftool version as well.
The rest of the changes are a rather straightforward conversion.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211023205154.6710-4-quentin@isovalent.com
2021-10-24 04:51:52 +08:00
|
|
|
if (!hashmap__empty(link_table)) {
|
|
|
|
struct hashmap_entry *entry;
|
2020-04-29 08:16:12 +08:00
|
|
|
|
libbpf: Hashmap interface update to allow both long and void* keys/values
An update for libbpf's hashmap interface from void* -> void* to a
polymorphic one, allowing both long and void* keys and values.
This simplifies many use cases in libbpf as hashmaps there are mostly
integer to integer.
Perf copies hashmap implementation from libbpf and has to be
updated as well.
Changes to libbpf, selftests/bpf and perf are packed as a single
commit to avoid compilation issues with any future bisect.
Polymorphic interface is acheived by hiding hashmap interface
functions behind auxiliary macros that take care of necessary
type casts, for example:
#define hashmap_cast_ptr(p) \
({ \
_Static_assert((p) == NULL || sizeof(*(p)) == sizeof(long),\
#p " pointee should be a long-sized integer or a pointer"); \
(long *)(p); \
})
bool hashmap_find(const struct hashmap *map, long key, long *value);
#define hashmap__find(map, key, value) \
hashmap_find((map), (long)(key), hashmap_cast_ptr(value))
- hashmap__find macro casts key and value parameters to long
and long* respectively
- hashmap_cast_ptr ensures that value pointer points to a memory
of appropriate size.
This hack was suggested by Andrii Nakryiko in [1].
This is a follow up for [2].
[1] https://lore.kernel.org/bpf/CAEf4BzZ8KFneEJxFAaNCCFPGqp20hSpS2aCj76uRk3-qZUH5xg@mail.gmail.com/
[2] https://lore.kernel.org/bpf/af1facf9-7bc8-8a3d-0db4-7b3f333589a2@meta.com/T/#m65b28f1d6d969fcd318b556db6a3ad499a42607d
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20221109142611.879983-2-eddyz87@gmail.com
2022-11-09 22:26:09 +08:00
|
|
|
hashmap__for_each_key_entry(link_table, entry, info->id)
|
|
|
|
printf("\n\tpinned %s", (char *)entry->pvalue);
|
2020-04-29 08:16:12 +08:00
|
|
|
}
|
bpftool: Switch to libbpf's hashmap for PIDs/names references
In order to show PIDs and names for processes holding references to BPF
programs, maps, links, or BTF objects, bpftool creates hash maps to
store all relevant information. This commit is part of a set that
transitions from the kernel's hash map implementation to the one coming
with libbpf.
The motivation is to make bpftool less dependent of kernel headers, to
ease the path to a potential out-of-tree mirror, like libbpf has.
This is the third and final step of the transition, in which we convert
the hash maps used for storing the information about the processes
holding references to BPF objects (programs, maps, links, BTF), and at
last we drop the inclusion of tools/include/linux/hashtable.h.
Note: Checkpatch complains about the use of __weak declarations, and the
missing empty lines after the bunch of empty function declarations when
compiling without the BPF skeletons (none of these were introduced in
this patch). We want to keep things as they are, and the reports should
be safe to ignore.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211023205154.6710-6-quentin@isovalent.com
2021-10-24 04:51:54 +08:00
|
|
|
emit_obj_refs_plain(refs_table, info->id, "\n\tpids ");
|
2020-04-29 08:16:12 +08:00
|
|
|
|
|
|
|
printf("\n");
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int do_show_link(int fd)
|
|
|
|
{
|
|
|
|
struct bpf_link_info info;
|
|
|
|
__u32 len = sizeof(info);
|
bpftool: Implement link_query for bpf iterators
The link query for bpf iterators is implemented.
Besides being shown to the user what bpf iterator
the link represents, the target_name is also used
to filter out what additional information should be
printed out, e.g., whether map_id should be shown or not.
The following is an example of bpf_iter link dump,
plain output or pretty output.
$ bpftool link show
11: iter prog 59 target_name task
pids test_progs(1749)
34: iter prog 173 target_name bpf_map_elem map_id 127
pids test_progs_1(1753)
$ bpftool -p link show
[{
"id": 11,
"type": "iter",
"prog_id": 59,
"target_name": "task",
"pids": [{
"pid": 1749,
"comm": "test_progs"
}
]
},{
"id": 34,
"type": "iter",
"prog_id": 173,
"target_name": "bpf_map_elem",
"map_id": 127,
"pids": [{
"pid": 1753,
"comm": "test_progs_1"
}
]
}
]
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200821184420.574430-1-yhs@fb.com
2020-08-22 02:44:20 +08:00
|
|
|
char buf[256];
|
2020-04-29 08:16:12 +08:00
|
|
|
int err;
|
|
|
|
|
|
|
|
memset(&info, 0, sizeof(info));
|
|
|
|
again:
|
2023-02-15 07:12:16 +08:00
|
|
|
err = bpf_link_get_info_by_fd(fd, &info, &len);
|
2020-04-29 08:16:12 +08:00
|
|
|
if (err) {
|
|
|
|
p_err("can't get link info: %s",
|
|
|
|
strerror(errno));
|
|
|
|
close(fd);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
if (info.type == BPF_LINK_TYPE_RAW_TRACEPOINT &&
|
|
|
|
!info.raw_tracepoint.tp_name) {
|
bpftool: Implement link_query for bpf iterators
The link query for bpf iterators is implemented.
Besides being shown to the user what bpf iterator
the link represents, the target_name is also used
to filter out what additional information should be
printed out, e.g., whether map_id should be shown or not.
The following is an example of bpf_iter link dump,
plain output or pretty output.
$ bpftool link show
11: iter prog 59 target_name task
pids test_progs(1749)
34: iter prog 173 target_name bpf_map_elem map_id 127
pids test_progs_1(1753)
$ bpftool -p link show
[{
"id": 11,
"type": "iter",
"prog_id": 59,
"target_name": "task",
"pids": [{
"pid": 1749,
"comm": "test_progs"
}
]
},{
"id": 34,
"type": "iter",
"prog_id": 173,
"target_name": "bpf_map_elem",
"map_id": 127,
"pids": [{
"pid": 1753,
"comm": "test_progs_1"
}
]
}
]
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200821184420.574430-1-yhs@fb.com
2020-08-22 02:44:20 +08:00
|
|
|
info.raw_tracepoint.tp_name = (unsigned long)&buf;
|
|
|
|
info.raw_tracepoint.tp_name_len = sizeof(buf);
|
|
|
|
goto again;
|
|
|
|
}
|
|
|
|
if (info.type == BPF_LINK_TYPE_ITER &&
|
|
|
|
!info.iter.target_name) {
|
|
|
|
info.iter.target_name = (unsigned long)&buf;
|
|
|
|
info.iter.target_name_len = sizeof(buf);
|
2020-04-29 08:16:12 +08:00
|
|
|
goto again;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (json_output)
|
|
|
|
show_link_close_json(fd, &info);
|
|
|
|
else
|
|
|
|
show_link_close_plain(fd, &info);
|
|
|
|
|
|
|
|
close(fd);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int do_show(int argc, char **argv)
|
|
|
|
{
|
|
|
|
__u32 id = 0;
|
|
|
|
int err, fd;
|
|
|
|
|
2021-10-24 04:51:51 +08:00
|
|
|
if (show_pinned) {
|
bpftool: Switch to libbpf's hashmap for pinned paths of BPF objects
In order to show pinned paths for BPF programs, maps, or links when
listing them with the "-f" option, bpftool creates hash maps to store
all relevant paths under the bpffs. So far, it would rely on the
kernel implementation (from tools/include/linux/hashtable.h).
We can make bpftool rely on libbpf's implementation instead. The
motivation is to make bpftool less dependent of kernel headers, to ease
the path to a potential out-of-tree mirror, like libbpf has.
This commit is the first step of the conversion: the hash maps for
pinned paths for programs, maps, and links are converted to libbpf's
hashmap.{c,h}. Other hash maps used for the PIDs of process holding
references to BPF objects are left unchanged for now. On the build side,
this requires adding a dependency to a second header internal to libbpf,
and making it a dependency for the bootstrap bpftool version as well.
The rest of the changes are a rather straightforward conversion.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211023205154.6710-4-quentin@isovalent.com
2021-10-24 04:51:52 +08:00
|
|
|
link_table = hashmap__new(hash_fn_for_key_as_id,
|
|
|
|
equal_fn_for_key_as_id, NULL);
|
2022-01-07 23:26:20 +08:00
|
|
|
if (IS_ERR(link_table)) {
|
bpftool: Switch to libbpf's hashmap for pinned paths of BPF objects
In order to show pinned paths for BPF programs, maps, or links when
listing them with the "-f" option, bpftool creates hash maps to store
all relevant paths under the bpffs. So far, it would rely on the
kernel implementation (from tools/include/linux/hashtable.h).
We can make bpftool rely on libbpf's implementation instead. The
motivation is to make bpftool less dependent of kernel headers, to ease
the path to a potential out-of-tree mirror, like libbpf has.
This commit is the first step of the conversion: the hash maps for
pinned paths for programs, maps, and links are converted to libbpf's
hashmap.{c,h}. Other hash maps used for the PIDs of process holding
references to BPF objects are left unchanged for now. On the build side,
this requires adding a dependency to a second header internal to libbpf,
and making it a dependency for the bootstrap bpftool version as well.
The rest of the changes are a rather straightforward conversion.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211023205154.6710-4-quentin@isovalent.com
2021-10-24 04:51:52 +08:00
|
|
|
p_err("failed to create hashmap for pinned paths");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
build_pinned_obj_table(link_table, BPF_OBJ_LINK);
|
2021-10-24 04:51:51 +08:00
|
|
|
}
|
tools/bpftool: Show info for processes holding BPF map/prog/link/btf FDs
Add bpf_iter-based way to find all the processes that hold open FDs against
BPF object (map, prog, link, btf). bpftool always attempts to discover this,
but will silently give up if kernel doesn't yet support bpf_iter BPF programs.
Process name and PID are emitted for each process (task group).
Sample output for each of 4 BPF objects:
$ sudo ./bpftool prog show
2694: cgroup_device tag 8c42dee26e8cd4c2 gpl
loaded_at 2020-06-16T15:34:32-0700 uid 0
xlated 648B jited 409B memlock 4096B
pids systemd(1)
2907: cgroup_skb name egress tag 9ad187367cf2b9e8 gpl
loaded_at 2020-06-16T18:06:54-0700 uid 0
xlated 48B jited 59B memlock 4096B map_ids 2436
btf_id 1202
pids test_progs(2238417), test_progs(2238445)
$ sudo ./bpftool map show
2436: array name test_cgr.bss flags 0x400
key 4B value 8B max_entries 1 memlock 8192B
btf_id 1202
pids test_progs(2238417), test_progs(2238445)
2445: array name pid_iter.rodata flags 0x480
key 4B value 4B max_entries 1 memlock 8192B
btf_id 1214 frozen
pids bpftool(2239612)
$ sudo ./bpftool link show
61: cgroup prog 2908
cgroup_id 375301 attach_type egress
pids test_progs(2238417), test_progs(2238445)
62: cgroup prog 2908
cgroup_id 375344 attach_type egress
pids test_progs(2238417), test_progs(2238445)
$ sudo ./bpftool btf show
1202: size 1527B prog_ids 2908,2907 map_ids 2436
pids test_progs(2238417), test_progs(2238445)
1242: size 34684B
pids bpftool(2258892)
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/20200619231703.738941-9-andriin@fb.com
2020-06-20 07:17:02 +08:00
|
|
|
build_obj_refs_table(&refs_table, BPF_OBJ_LINK);
|
2020-04-29 08:16:12 +08:00
|
|
|
|
|
|
|
if (argc == 2) {
|
|
|
|
fd = link_parse_fd(&argc, &argv);
|
|
|
|
if (fd < 0)
|
|
|
|
return fd;
|
|
|
|
return do_show_link(fd);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (argc)
|
|
|
|
return BAD_ARG();
|
|
|
|
|
|
|
|
if (json_output)
|
|
|
|
jsonw_start_array(json_wtr);
|
|
|
|
while (true) {
|
|
|
|
err = bpf_link_get_next_id(id, &id);
|
|
|
|
if (err) {
|
|
|
|
if (errno == ENOENT)
|
|
|
|
break;
|
|
|
|
p_err("can't get next link: %s%s", strerror(errno),
|
|
|
|
errno == EINVAL ? " -- kernel too old?" : "");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
fd = bpf_link_get_fd_by_id(id);
|
|
|
|
if (fd < 0) {
|
|
|
|
if (errno == ENOENT)
|
|
|
|
continue;
|
|
|
|
p_err("can't get link by id (%u): %s",
|
|
|
|
id, strerror(errno));
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = do_show_link(fd);
|
|
|
|
if (err)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (json_output)
|
|
|
|
jsonw_end_array(json_wtr);
|
|
|
|
|
bpftool: Switch to libbpf's hashmap for PIDs/names references
In order to show PIDs and names for processes holding references to BPF
programs, maps, links, or BTF objects, bpftool creates hash maps to
store all relevant information. This commit is part of a set that
transitions from the kernel's hash map implementation to the one coming
with libbpf.
The motivation is to make bpftool less dependent of kernel headers, to
ease the path to a potential out-of-tree mirror, like libbpf has.
This is the third and final step of the transition, in which we convert
the hash maps used for storing the information about the processes
holding references to BPF objects (programs, maps, links, BTF), and at
last we drop the inclusion of tools/include/linux/hashtable.h.
Note: Checkpatch complains about the use of __weak declarations, and the
missing empty lines after the bunch of empty function declarations when
compiling without the BPF skeletons (none of these were introduced in
this patch). We want to keep things as they are, and the reports should
be safe to ignore.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211023205154.6710-6-quentin@isovalent.com
2021-10-24 04:51:54 +08:00
|
|
|
delete_obj_refs_table(refs_table);
|
tools/bpftool: Show info for processes holding BPF map/prog/link/btf FDs
Add bpf_iter-based way to find all the processes that hold open FDs against
BPF object (map, prog, link, btf). bpftool always attempts to discover this,
but will silently give up if kernel doesn't yet support bpf_iter BPF programs.
Process name and PID are emitted for each process (task group).
Sample output for each of 4 BPF objects:
$ sudo ./bpftool prog show
2694: cgroup_device tag 8c42dee26e8cd4c2 gpl
loaded_at 2020-06-16T15:34:32-0700 uid 0
xlated 648B jited 409B memlock 4096B
pids systemd(1)
2907: cgroup_skb name egress tag 9ad187367cf2b9e8 gpl
loaded_at 2020-06-16T18:06:54-0700 uid 0
xlated 48B jited 59B memlock 4096B map_ids 2436
btf_id 1202
pids test_progs(2238417), test_progs(2238445)
$ sudo ./bpftool map show
2436: array name test_cgr.bss flags 0x400
key 4B value 8B max_entries 1 memlock 8192B
btf_id 1202
pids test_progs(2238417), test_progs(2238445)
2445: array name pid_iter.rodata flags 0x480
key 4B value 4B max_entries 1 memlock 8192B
btf_id 1214 frozen
pids bpftool(2239612)
$ sudo ./bpftool link show
61: cgroup prog 2908
cgroup_id 375301 attach_type egress
pids test_progs(2238417), test_progs(2238445)
62: cgroup prog 2908
cgroup_id 375344 attach_type egress
pids test_progs(2238417), test_progs(2238445)
$ sudo ./bpftool btf show
1202: size 1527B prog_ids 2908,2907 map_ids 2436
pids test_progs(2238417), test_progs(2238445)
1242: size 34684B
pids bpftool(2258892)
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/20200619231703.738941-9-andriin@fb.com
2020-06-20 07:17:02 +08:00
|
|
|
|
2021-10-24 04:51:51 +08:00
|
|
|
if (show_pinned)
|
bpftool: Switch to libbpf's hashmap for pinned paths of BPF objects
In order to show pinned paths for BPF programs, maps, or links when
listing them with the "-f" option, bpftool creates hash maps to store
all relevant paths under the bpffs. So far, it would rely on the
kernel implementation (from tools/include/linux/hashtable.h).
We can make bpftool rely on libbpf's implementation instead. The
motivation is to make bpftool less dependent of kernel headers, to ease
the path to a potential out-of-tree mirror, like libbpf has.
This commit is the first step of the conversion: the hash maps for
pinned paths for programs, maps, and links are converted to libbpf's
hashmap.{c,h}. Other hash maps used for the PIDs of process holding
references to BPF objects are left unchanged for now. On the build side,
this requires adding a dependency to a second header internal to libbpf,
and making it a dependency for the bootstrap bpftool version as well.
The rest of the changes are a rather straightforward conversion.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211023205154.6710-4-quentin@isovalent.com
2021-10-24 04:51:52 +08:00
|
|
|
delete_pinned_obj_table(link_table);
|
2021-10-24 04:51:51 +08:00
|
|
|
|
2020-04-29 08:16:12 +08:00
|
|
|
return errno == ENOENT ? 0 : -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int do_pin(int argc, char **argv)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = do_pin_any(argc, argv, link_parse_fd);
|
|
|
|
if (!err && json_output)
|
|
|
|
jsonw_null(json_wtr);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2020-08-01 02:28:29 +08:00
|
|
|
static int do_detach(int argc, char **argv)
|
|
|
|
{
|
|
|
|
int err, fd;
|
|
|
|
|
|
|
|
if (argc != 2) {
|
|
|
|
p_err("link specifier is invalid or missing\n");
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
fd = link_parse_fd(&argc, &argv);
|
|
|
|
if (fd < 0)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
err = bpf_link_detach(fd);
|
|
|
|
if (err)
|
|
|
|
err = -errno;
|
|
|
|
close(fd);
|
|
|
|
if (err) {
|
|
|
|
p_err("failed link detach: %s", strerror(-err));
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (json_output)
|
|
|
|
jsonw_null(json_wtr);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-04-29 08:16:12 +08:00
|
|
|
static int do_help(int argc, char **argv)
|
|
|
|
{
|
|
|
|
if (json_output) {
|
|
|
|
jsonw_null(json_wtr);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
fprintf(stderr,
|
|
|
|
"Usage: %1$s %2$s { show | list } [LINK]\n"
|
|
|
|
" %1$s %2$s pin LINK FILE\n"
|
2020-08-01 02:28:29 +08:00
|
|
|
" %1$s %2$s detach LINK\n"
|
2020-04-29 08:16:12 +08:00
|
|
|
" %1$s %2$s help\n"
|
|
|
|
"\n"
|
|
|
|
" " HELP_SPEC_LINK "\n"
|
2021-07-31 05:54:32 +08:00
|
|
|
" " HELP_SPEC_OPTIONS " |\n"
|
|
|
|
" {-f|--bpffs} | {-n|--nomount} }\n"
|
2020-04-29 08:16:12 +08:00
|
|
|
"",
|
|
|
|
bin_name, argv[-2]);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct cmd cmds[] = {
|
|
|
|
{ "show", do_show },
|
|
|
|
{ "list", do_show },
|
|
|
|
{ "help", do_help },
|
|
|
|
{ "pin", do_pin },
|
2020-08-01 02:28:29 +08:00
|
|
|
{ "detach", do_detach },
|
2020-04-29 08:16:12 +08:00
|
|
|
{ 0 }
|
|
|
|
};
|
|
|
|
|
|
|
|
int do_link(int argc, char **argv)
|
|
|
|
{
|
|
|
|
return cmd_select(cmds, argc, argv, do_help);
|
|
|
|
}
|