bpftool-btf

title: bpftool-btf(8)

summary: tool for inspection of BTF data

text:
# bpftool-btf(8)

## Name
bpftool-btf - tool for inspection of BTF data

## SYNOPSIS
bpftool [OPTIONS] btf COMMAND

OPTIONS := { { -j | --json } [{ -p | --pretty }] | { -d | --debug } | { -B | --base-btf } }

COMMANDS := { dump | help }

## BTF COMMANDS

```
bpftool btf { show | list } [id BTF_ID]
bpftool btf dump BTF_SRC [format FORMAT] [root_id ROOT_ID]
bpftool btf help
BTF_SRC := { id BTF_ID | prog PROG | map MAP [{key | value | kv | all}] | file FILE }
FORMAT := { raw | c [unsorted] }
MAP := { id MAP_ID | pinned FILE }
PROG := { id PROG_ID | pinned FILE | tag PROG_TAG | name PROG_NAME }
```

## DESCRIPTION
bpftool btf { show | list } [id BTF_ID]

Show information about loaded BTF objects. If a BTF ID is specified, show information only about given BTF object, otherwise list all BTF objects currently loaded on the system. Since Linux 5.8 bpftool is able to discover information about processes that hold open file descriptors (FDs) against BTF objects. On such kernels bpftool will automatically emit this information as well.

bpftool btf dump BTF_SRC [format FORMAT] [root_id ROOT_ID]

Dump BTF entries from a given BTF_SRC. When id is specified, BTF object with that ID will be loaded and all its BTF types emitted.

When map is provided, it's expected that map has associated BTF object with BTF types describing key and value. It's possible to select whether to dump only BTF type(s) associated with key (key), value (value), both key and value (kv), or all BTF types present in associated BTF object (all). If not specified, kv is assumed.

When prog is provided, it's expected that program has associated BTF object with BTF types.

When specifying FILE, an ELF file is expected, containing .BTF section with well-defined BTF binary format data, typically produced by clang or pahole.

format option can be used to override default (raw) output format. Raw (raw) or C-syntax (c) output formats are supported. With C-style formatting, the output is sorted by default. Use the unsorted option to avoid sorting the output.

root_id option can be used to filter a dump to a single type and all its dependent types. It cannot be used with any other types of filtering (such as the "key", "value", or "kv" arguments when dumping BTF for a map). It can be passed multiple times to dump multiple types.

bpftool btf help

Print short help message.

## OPTIONS
-h, --help

Print short help message (similar to bpftool help).

-V, --version

Print bpftool's version number (similar to bpftool version), the number of the libbpf version in use, and optional features that were included when bpftool was compiled. Optional features include linking against LLVM or libbfd to provide the disassembler for JIT-ted programs (bpftool prog dump jited) and usage of BPF skeletons (some features like bpftool prog profile or showing pids associated to BPF objects may rely on it).

-j, --json

Generate JSON output. For commands that cannot produce JSON, this option has no effect.

-p, --pretty

Generate human-readable JSON output. Implies -j.

-d, --debug

Print all logs available, even debug-level information. This includes logs from libbpf as well as from the verifier, when attempting to load programs.

-B, --base-btf FILE

Pass a base BTF object. Base BTF objects are typically used with BTF objects for kernel modules. To avoid duplicating all kernel symbols required by modules, BTF objects for modules are "split", they are built incrementally on top of the kernel (vmlinux) BTF object. So the base BTF reference should usually point to the kernel BTF. When the main BTF object to process (for example, the module BTF to dump) is passed as a FILE, bpftool attempts to autodetect the path for the base object, and passing this option is optional. When the main BTF object is passed through other handles, this option becomes necessary.

## EXAMPLES
\# bpftool btf dump id 1226

```
[1] PTR '(anon)' type_id=2
[2] STRUCT 'dummy_tracepoint_args' size=16 vlen=2

        'pad' type_id=3 bits_offset=0

        'sock' type_id=4 bits_offset=64
[3] INT 'long long unsigned int' size=8 bits_offset=0 nr_bits=64 encoding=(none)
[4] PTR '(anon)' type_id=5
[5] FWD 'sock' fwd_kind=union
```

This gives an example of default output for all supported BTF kinds.

$ cat prog.c

```
struct fwd_struct;
enum my_enum {

        VAL1 = 3,

        VAL2 = 7,
};
typedef struct my_struct my_struct_t;
struct my_struct {

        const unsigned int const_int_field;

        int bitfield_field: 4;

        char arr_field[16];

        const struct fwd_struct *restrict fwd_field;

        enum my_enum enum_field;

        volatile my_struct_t *typedef_ptr_field;
};
union my_union {

        int a;

        struct my_struct b;
};
struct my_struct struct_global_var __attribute__((section("data_sec"))) = {

        .bitfield_field = 3,

        .enum_field = VAL1,
};
int global_var __attribute__((section("data_sec"))) = 7;
__attribute__((noinline))
int my_func(union my_union *arg1, int arg2)
{

        static int static_var __attribute__((section("data_sec"))) = 123;

        static_var++;

        return static_var;
}
```

$ bpftool btf dump file prog.o

```
[1] PTR '(anon)' type_id=2
[2] UNION 'my_union' size=48 vlen=2

        'a' type_id=3 bits_offset=0

        'b' type_id=4 bits_offset=0
[3] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[4] STRUCT 'my_struct' size=48 vlen=6

        'const_int_field' type_id=5 bits_offset=0

        'bitfield_field' type_id=3 bits_offset=32 bitfield_size=4

        'arr_field' type_id=8 bits_offset=40

        'fwd_field' type_id=10 bits_offset=192

        'enum_field' type_id=14 bits_offset=256

        'typedef_ptr_field' type_id=15 bits_offset=320
[5] CONST '(anon)' type_id=6
[6] INT 'unsigned int' size=4 bits_offset=0 nr_bits=32 encoding=(none)
[7] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED
[8] ARRAY '(anon)' type_id=7 index_type_id=9 nr_elems=16
[9] INT '__ARRAY_SIZE_TYPE__' size=4 bits_offset=0 nr_bits=32 encoding=(none)
[10] RESTRICT '(anon)' type_id=11
[11] PTR '(anon)' type_id=12
[12] CONST '(anon)' type_id=13
[13] FWD 'fwd_struct' fwd_kind=union
[14] ENUM 'my_enum' size=4 vlen=2

        'VAL1' val=3

        'VAL2' val=7
[15] PTR '(anon)' type_id=16
[16] VOLATILE '(anon)' type_id=17
[17] TYPEDEF 'my_struct_t' type_id=4
[18] FUNC_PROTO '(anon)' ret_type_id=3 vlen=2

        'arg1' type_id=1

        'arg2' type_id=3
[19] FUNC 'my_func' type_id=18
[20] VAR 'struct_global_var' type_id=4, linkage=global-alloc
[21] VAR 'global_var' type_id=3, linkage=global-alloc
[22] VAR 'my_func.static_var' type_id=3, linkage=static
[23] DATASEC 'data_sec' size=0 vlen=3

        type_id=20 offset=0 size=48

        type_id=21 offset=0 size=4

        type_id=22 offset=52 size=4
```

The following commands print BTF types associated with specified map's key, value, both key and value, and all BTF types, respectively. By default, both key and value types will be printed.

\# bpftool btf dump map id 123 key

```
[39] TYPEDEF 'u32' type_id=37
```

\# bpftool btf dump map id 123 value

```
[86] PTR '(anon)' type_id=87
```

\# bpftool btf dump map id 123 kv

```
[39] TYPEDEF 'u32' type_id=37
[86] PTR '(anon)' type_id=87
```

\# bpftool btf dump map id 123 all

```
[1] PTR '(anon)' type_id=0
.
.
.
[2866] ARRAY '(anon)' type_id=52 index_type_id=51 nr_elems=4
```

All the standard ways to specify map or program are supported:

\# bpftool btf dump map id 123

\# bpftool btf dump map pinned /sys/fs/bpf/map_name

\# bpftool btf dump prog id 456

\# bpftool btf dump prog tag b88e0a09b1d9759d

\# bpftool btf dump prog pinned /sys/fs/bpf/prog_name

```
# bpftool btf dump file /sys/kernel/btf/i2c_smbus
(or)
# I2C_SMBUS_ID=$(bpftool btf show -p | jq '.[] | select(.name=="i2c_smbus").id')
# bpftool btf dump id ${I2C_SMBUS_ID} -B /sys/kernel/btf/vmlinux
```

```
[104848] STRUCT 'i2c_smbus_alert' size=40 vlen=2

        'alert' type_id=393 bits_offset=0

        'ara' type_id=56050 bits_offset=256
[104849] STRUCT 'alert_data' size=12 vlen=3

        'addr' type_id=16 bits_offset=0

        'type' type_id=56053 bits_offset=32

        'data' type_id=7 bits_offset=64
[104850] PTR '(anon)' type_id=104848
[104851] PTR '(anon)' type_id=104849
[104852] FUNC 'i2c_register_spd' type_id=84745 linkage=static
[104853] FUNC 'smbalert_driver_init' type_id=1213 linkage=static
[104854] FUNC_PROTO '(anon)' ret_type_id=18 vlen=1

        'ara' type_id=56050
[104855] FUNC 'i2c_handle_smbus_alert' type_id=104854 linkage=static
[104856] FUNC 'smbalert_remove' type_id=104854 linkage=static
[104857] FUNC_PROTO '(anon)' ret_type_id=18 vlen=2

        'ara' type_id=56050

        'id' type_id=56056
[104858] FUNC 'smbalert_probe' type_id=104857 linkage=static
[104859] FUNC 'smbalert_work' type_id=9695 linkage=static
[104860] FUNC 'smbus_alert' type_id=71367 linkage=static
[104861] FUNC 'smbus_do_alert' type_id=84827 linkage=static
```

## SEE ALSO
bpf(2), bpf-helpers(7), bpftool(8), bpftool-cgroup(8), bpftool-feature(8), bpftool-gen(8), bpftool-iter(8), bpftool-link(8), bpftool-map(8), bpftool-net(8), bpftool-perf(8), bpftool-prog(8), bpftool-struct_ops(8), bpftool-token(8)


bpftool-cgroup

package: bpftool

title: bpftool-cgroup(8)

text:
# bpftool-cgroup(8)

## Name
bpftool-cgroup - tool for inspection and simple manipulation of eBPF progs

## SYNOPSIS
bpftool [OPTIONS] cgroup COMMAND

OPTIONS := { { -j | --json } [{ -p | --pretty }] | { -d | --debug } | { -f | --bpffs } }

COMMANDS := { show | list | tree | attach | detach | help }

## CGROUP COMMANDS

```
bpftool cgroup { show | list } CGROUP [effective]
bpftool cgroup tree [CGROUP_ROOT] [effective]
bpftool cgroup attach CGROUP ATTACH_TYPE PROG [ATTACH_FLAGS]
bpftool cgroup detach CGROUP ATTACH_TYPE PROG
bpftool cgroup help
PROG := { id PROG_ID | pinned FILE | tag PROG_TAG | name PROG_NAME }
ATTACH_TYPE := { cgroup_inet_ingress | cgroup_inet_egress |

cgroup_inet_sock_create | cgroup_sock_ops |
cgroup_device | cgroup_inet4_bind | cgroup_inet6_bind |
cgroup_inet4_post_bind | cgroup_inet6_post_bind |
cgroup_inet4_connect | cgroup_inet6_connect |
cgroup_unix_connect | cgroup_inet4_getpeername |
cgroup_inet6_getpeername | cgroup_unix_getpeername |
cgroup_inet4_getsockname | cgroup_inet6_getsockname |
cgroup_unix_getsockname | cgroup_udp4_sendmsg |
cgroup_udp6_sendmsg | cgroup_unix_sendmsg |
cgroup_udp4_recvmsg | cgroup_udp6_recvmsg |
cgroup_unix_recvmsg | cgroup_sysctl |
cgroup_getsockopt | cgroup_setsockopt |
cgroup_inet_sock_release }

ATTACH_FLAGS := { multi | override }
```

## DESCRIPTION
bpftool cgroup { show | list } CGROUP [effective]

List all programs attached to the cgroup CGROUP. Output will start with program ID followed by attach type, attach flags and program name.

If effective is specified retrieve effective programs that will execute for events within a cgroup. This includes inherited along with attached ones.

bpftool cgroup tree [CGROUP_ROOT] [effective]

Iterate over all cgroups in CGROUP_ROOT and list all attached programs. If CGROUP_ROOT is not specified, bpftool uses cgroup v2 mountpoint. The output is similar to the output of cgroup show/list commands: it starts with absolute cgroup path, followed by program ID, attach type, attach flags and program name.

If effective is specified retrieve effective programs that will execute for events within a cgroup. This includes inherited along with attached ones.

bpftool cgroup attach CGROUP ATTACH_TYPE PROG [ATTACH_FLAGS]

Attach program PROG to the cgroup CGROUP with attach type ATTACH_TYPE and optional ATTACH_FLAGS. ATTACH_FLAGS can be one of: override if a sub-cgroup installs some bpf program, the program in this cgroup yields to sub-cgroup program; multi if a sub-cgroup installs some bpf program, that cgroup program gets run in addition to the program in this cgroup.

Only one program is allowed to be attached to a cgroup with no attach flags or the override flag. Attaching another program will release old program and attach the new one.

Multiple programs are allowed to be attached to a cgroup with multi. They are executed in FIFO order (those that were attached first, run first).

Non-default ATTACH_FLAGS are supported by kernel version 4.14 and later.

ATTACH_TYPE can be one of:

- ingress ingress path of the inet socket (since 4.10)

- egress egress path of the inet socket (since 4.10)

- sock_create opening of an inet socket (since 4.10)

- sock_ops various socket operations (since 4.12)

- device device access (since 4.15)

- bind4 call to bind(2) for an inet4 socket (since 4.17)

- bind6 call to bind(2) for an inet6 socket (since 4.17)

- post_bind4 return from bind(2) for an inet4 socket (since 4.17)

- post_bind6 return from bind(2) for an inet6 socket (since 4.17)

- connect4 call to connect(2) for an inet4 socket (since 4.17)

- connect6 call to connect(2) for an inet6 socket (since 4.17)

- connect_unix call to connect(2) for a unix socket (since 6.7)

- sendmsg4 call to sendto(2), sendmsg(2), sendmmsg(2) for an unconnected udp4 socket (since 4.18)

- sendmsg6 call to sendto(2), sendmsg(2), sendmmsg(2) for an unconnected udp6 socket (since 4.18)

- sendmsg_unix call to sendto(2), sendmsg(2), sendmmsg(2) for an unconnected unix socket (since 6.7)

- recvmsg4 call to recvfrom(2), recvmsg(2), recvmmsg(2) for an unconnected udp4 socket (since 5.2)

- recvmsg6 call to recvfrom(2), recvmsg(2), recvmmsg(2) for an unconnected udp6 socket (since 5.2)

- recvmsg_unix call to recvfrom(2), recvmsg(2), recvmmsg(2) for an unconnected unix socket (since 6.7)

- sysctl sysctl access (since 5.2)

- getsockopt call to getsockopt (since 5.3)

- setsockopt call to setsockopt (since 5.3)

- getpeername4 call to getpeername(2) for an inet4 socket (since 5.8)

- getpeername6 call to getpeername(2) for an inet6 socket (since 5.8)

- getpeername_unix call to getpeername(2) for a unix socket (since 6.7)

- getsockname4 call to getsockname(2) for an inet4 socket (since 5.8)

- getsockname6 call to getsockname(2) for an inet6 socket (since 5.8)

- getsockname_unix call to getsockname(2) for a unix socket (since 6.7)

- sock_release closing a userspace inet socket (since 5.9)

bpftool cgroup detach CGROUP ATTACH_TYPE PROG

Detach PROG from the cgroup CGROUP and attach type ATTACH_TYPE.

bpftool prog help

Print short help message.

## OPTIONS
-h, --help

Print short help message (similar to bpftool help).

-V, --version

Print bpftool's version number (similar to bpftool version), the number of the libbpf version in use, and optional features that were included when bpftool was compiled. Optional features include linking against LLVM or libbfd to provide the disassembler for JIT-ted programs (bpftool prog dump jited) and usage of BPF skeletons (some features like bpftool prog profile or showing pids associated to BPF objects may rely on it).

-j, --json

Generate JSON output. For commands that cannot produce JSON, this option has no effect.

-p, --pretty

Generate human-readable JSON output. Implies -j.

-d, --debug

Print all logs available, even debug-level information. This includes logs from libbpf as well as from the verifier, when attempting to load programs.

-f, --bpffs

Show file names of pinned programs.

## EXAMPLES

```
# mount -t bpf none /sys/fs/bpf/
# mkdir /sys/fs/cgroup/test.slice
# bpftool prog load ./device_cgroup.o /sys/fs/bpf/prog
# bpftool cgroup attach /sys/fs/cgroup/test.slice/ device id 1 allow_multi
```

\# bpftool cgroup list /sys/fs/cgroup/test.slice/

```
ID       AttachType      AttachFlags     Name
1        device          allow_multi     bpf_prog1
```

```
# bpftool cgroup detach /sys/fs/cgroup/test.slice/ device id 1
# bpftool cgroup list /sys/fs/cgroup/test.slice/
```

```
ID       AttachType      AttachFlags     Name
```

## SEE ALSO
bpf(2), bpf-helpers(7), bpftool(8), bpftool-btf(8), bpftool-feature(8), bpftool-gen(8), bpftool-iter(8), bpftool-link(8), bpftool-map(8), bpftool-net(8), bpftool-perf(8), bpftool-prog(8), bpftool-struct_ops(8), bpftool-token(8)

branch: sisyphus


bpftool-feature

title: bpftool-feature(8)

text:
# bpftool-feature(8)

## Name
bpftool-feature - tool for inspection of eBPF-related parameters for Linux kernel or net device

## SYNOPSIS
bpftool [OPTIONS] feature COMMAND

OPTIONS := { { -j | --json } [{ -p | --pretty }] | { -d | --debug } }

COMMANDS := { probe | help }

## FEATURE COMMANDS

```
bpftool feature probe [COMPONENT] [full] [unprivileged] [macros [prefix PREFIX]]
bpftool feature list_builtins GROUP
bpftool feature help
COMPONENT := { kernel | dev NAME }
GROUP := { prog_types | map_types | attach_types | link_types | helpers }
```

## DESCRIPTION
bpftool feature probe [kernel] [full] [macros [prefix PREFIX]]

Probe the running kernel and dump a number of eBPF-related parameters, such as availability of the bpf() system call, JIT status, eBPF program types availability, eBPF helper functions availability, and more. By default, bpftool does not run probes for bpf_probe_write_user() and bpf_trace_printk() helpers which print warnings to kernel logs. To enable them and run all probes, the full keyword should be used.

If the macros keyword (but not the -j option) is passed, a subset of the output is dumped as a list of #define macros that are ready to be included in a C header file, for example. If, additionally, prefix is used to define a PREFIX, the provided string will be used as a prefix to the names of the macros: this can be used to avoid conflicts on macro names when including the output of this command as a header file.

Keyword kernel can be omitted. If no probe target is specified, probing the kernel is the default behaviour.

When the unprivileged keyword is used, bpftool will dump only the features available to a user who does not have the CAP_SYS_ADMIN capability set. The features available in that case usually represent a small subset of the parameters supported by the system. Unprivileged users MUST use the unprivileged keyword: This is to avoid misdetection if bpftool is inadvertently run as non-root, for example. This keyword is unavailable if bpftool was compiled without libcap.

bpftool feature probe dev NAME [full] [macros [prefix PREFIX]]

Probe network device for supported eBPF features and dump results to the console. The keywords full, macros and prefix have the same role as when probing the kernel.

bpftool feature list_builtins GROUP

List items known to bpftool. These can be BPF program types (prog_types), BPF map types (map_types), attach types (attach_types), link types (link_types), or BPF helper functions (helpers). The command does not probe the system, but simply lists the elements that bpftool knows from compilation time, as provided from libbpf (for all object types) or from the BPF UAPI header (list of helpers). This can be used in scripts to iterate over BPF types or helpers.

bpftool feature help

Print short help message.

## OPTIONS
-h, --help

Print short help message (similar to bpftool help).

-V, --version

Print bpftool's version number (similar to bpftool version), the number of the libbpf version in use, and optional features that were included when bpftool was compiled. Optional features include linking against LLVM or libbfd to provide the disassembler for JIT-ted programs (bpftool prog dump jited) and usage of BPF skeletons (some features like bpftool prog profile or showing pids associated to BPF objects may rely on it).

-j, --json

Generate JSON output. For commands that cannot produce JSON, this option has no effect.

-p, --pretty

Generate human-readable JSON output. Implies -j.

-d, --debug

Print all logs available, even debug-level information. This includes logs from libbpf as well as from the verifier, when attempting to load programs.

## SEE ALSO
bpf(2), bpf-helpers(7), bpftool(8), bpftool-btf(8), bpftool-cgroup(8), bpftool-gen(8), bpftool-iter(8), bpftool-link(8), bpftool-map(8), bpftool-net(8), bpftool-perf(8), bpftool-prog(8), bpftool-struct_ops(8), bpftool-token(8)


bpftool-gen

title: bpftool-gen(8)

summary: tool for BPF code-generation

text:
# bpftool-gen(8)

## Name
bpftool-gen - tool for BPF code-generation

## SYNOPSIS
bpftool [OPTIONS] gen COMMAND

OPTIONS := { { -j | --json } [{ -p | --pretty }] | { -d | --debug } | { -L | --use-loader } | [ { -S | --sign } {-k <private_key.pem>} -i <certificate.x509> ] }

COMMAND := { object | skeleton | help }

## GEN COMMANDS

```
bpftool gen object OUTPUT_FILE INPUT_FILE [INPUT_FILE...]
bpftool gen skeleton FILE [name OBJECT_NAME]
bpftool gen subskeleton FILE [name OBJECT_NAME]
bpftool gen min_core_btf INPUT OUTPUT OBJECT [OBJECT...]
bpftool gen help
```

## DESCRIPTION
bpftool gen object OUTPUT_FILE INPUT_FILE [INPUT_FILE...]

Statically link (combine) together one or more INPUT_FILE's into a single resulting OUTPUT_FILE. All the files involved are BPF ELF object files. The rules of BPF static linking are mostly the same as for user-space object files, but in addition to combining data and instruction sections, .BTF and .BTF.ext (if present in any of the input files) data are combined together. .BTF data is deduplicated, so all the common types across INPUT_FILE's will only be represented once in the resulting BTF information.

BPF static linking allows to partition BPF source code into individually compiled files that are then linked into a single resulting BPF object file, which can be used to generated BPF skeleton (with gen skeleton command) or passed directly into libbpf (using bpf_object__open() family of APIs).

bpftool gen skeleton FILE

Generate BPF skeleton C header file for a given FILE. BPF skeleton is an alternative interface to existing libbpf APIs for working with BPF objects. Skeleton code is intended to significantly shorten and simplify code to load and work with BPF programs from userspace side. Generated code is tailored to specific input BPF object FILE, reflecting its structure by listing out available maps, program, variables, etc. Skeleton eliminates the need to lookup mentioned components by name. Instead, if skeleton instantiation succeeds, they are populated in skeleton structure as valid libbpf types (e.g., struct bpf_map pointer) and can be passed to existing generic libbpf APIs.

In addition to simple and reliable access to maps and programs, skeleton provides a storage for BPF links (struct bpf_link) for each BPF program within BPF object. When requested, supported BPF programs will be automatically attached and resulting BPF links stored for further use by user in pre-allocated fields in skeleton struct. For BPF programs that can't be automatically attached by libbpf, user can attach them manually, but store resulting BPF link in per-program link field. All such set up links will be automatically destroyed on BPF skeleton destruction. This eliminates the need for users to manage links manually and rely on libbpf support to detach programs and free up resources.

Another facility provided by BPF skeleton is an interface to global variables of all supported kinds: mutable, read-only, as well as extern ones. This interface allows to pre-setup initial values of variables before BPF object is loaded and verified by kernel. For non-read-only variables, the same interface can be used to fetch values of global variables on userspace side, even if they are modified by BPF code.

During skeleton generation, contents of source BPF object FILE is embedded within generated code and is thus not necessary to keep around. This ensures skeleton and BPF object file are matching 1-to-1 and always stay in sync. Generated code is dual-licensed under LGPL-2.1 and BSD-2-Clause licenses.

It is a design goal and guarantee that skeleton interfaces are interoperable with generic libbpf APIs. User should always be able to use skeleton API to create and load BPF object, and later use libbpf APIs to keep working with specific maps, programs, etc.

As part of skeleton, few custom functions are generated. Each of them is prefixed with object name. Object name can either be derived from object file name, i.e., if BPF object file name is example.o, BPF object name will be example. Object name can be also specified explicitly through name OBJECT_NAME parameter. The following custom functions are provided (assuming example as the object name):

- example__open and example__open_opts. These functions are used to instantiate skeleton. It corresponds to libbpf's bpf_object__open() API. _opts variants accepts extra bpf_object_open_opts options.

- example__load. This function creates maps, loads and verifies BPF programs, initializes global data maps. It corresponds to libbpf's bpf_object__load() API.

- example__open_and_load combines example__open and example__load invocations in one commonly used operation.

- example__attach and example__detach. This pair of functions allow to attach and detach, correspondingly, already loaded BPF object. Only BPF programs of types supported by libbpf for auto-attachment will be auto-attached and their corresponding BPF links instantiated. For other BPF programs, user can manually create a BPF link and assign it to corresponding fields in skeleton struct. example__detach will detach both links created automatically, as well as those populated by user manually.

- example__destroy. Detach and unload BPF programs, free up all the resources used by skeleton and BPF object.

If BPF object has global variables, corresponding structs with memory layout corresponding to global data data section layout will be created. Currently supported ones are: .data, .bss, .rodata, and .kconfig structs/data sections. These data sections/structs can be used to set up initial values of variables, if set before example__load. Afterwards, if target kernel supports memory-mapped BPF arrays, same structs can be used to fetch and update (non-read-only) data from userspace, with same simplicity as for BPF side.

bpftool gen subskeleton FILE

Generate BPF subskeleton C header file for a given FILE. Subskeletons are similar to skeletons, except they do not own the corresponding maps, programs, or global variables. They require that the object file used to generate them is already loaded into a bpf_object by some other means.

This functionality is useful when a library is included into a larger BPF program. A subskeleton for the library would have access to all objects and globals defined in it, without having to know about the larger program.

Consequently, there are only two functions defined for subskeletons:

- example__open(bpf_object*). Instantiates a subskeleton from an already opened (but not necessarily loaded) bpf_object.

- example__destroy(). Frees the storage for the subskeleton but does not unload any BPF programs or maps.

bpftool gen min_core_btf INPUT OUTPUT OBJECT [OBJECT...]

Generate a minimum BTF file as OUTPUT, derived from a given INPUT BTF file, containing all needed BTF types so one, or more, given eBPF objects CO-RE relocations may be satisfied. When kernels aren't compiled with CONFIG_DEBUG_INFO_BTF, libbpf, when loading an eBPF object, has to rely on external BTF files to be able to calculate CO-RE relocations.

Usually, an external BTF file is built from existing kernel DWARF data using pahole. It contains all the types used by its respective kernel image and, because of that, is big.

The min_core_btf feature builds smaller BTF files, customized to one or multiple eBPF objects, so they can be distributed together with an eBPF CO-RE based application, turning the application portable to different kernel versions.

Check examples below for more information on how to use it.

bpftool gen help

Print short help message.

## OPTIONS
-h, --help

Print short help message (similar to bpftool help).

-V, --version

Print bpftool's version number (similar to bpftool version), the number of the libbpf version in use, and optional features that were included when bpftool was compiled. Optional features include linking against LLVM or libbfd to provide the disassembler for JIT-ted programs (bpftool prog dump jited) and usage of BPF skeletons (some features like bpftool prog profile or showing pids associated to BPF objects may rely on it).

-j, --json

Generate JSON output. For commands that cannot produce JSON, this option has no effect.

-p, --pretty

Generate human-readable JSON output. Implies -j.

-d, --debug

Print all logs available, even debug-level information. This includes logs from libbpf as well as from the verifier, when attempting to load programs.

-L, --use-loader

For skeletons, generate a "light" skeleton (also known as "loader" skeleton). A light skeleton contains a loader eBPF program. It does not use the majority of the libbpf infrastructure, and does not need libelf.

-S, --sign

For skeletons, generate a signed skeleton. This option must be used with -k and -i. Using this flag implicitly enables --use-loader.

-k <private_key.pem>

Path to the private key file in PEM format, required for signing.

-i <certificate.x509>

Path to the X.509 certificate file in PEM or DER format, required for signing.

## EXAMPLES
$ cat example1.bpf.c

```
#include <stdbool.h>
#include <linux/ptrace.h>
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
const volatile int param1 = 42;
bool global_flag = true;
struct { int x; } data = {};
SEC("raw_tp/sys_enter")
int handle_sys_enter(struct pt_regs *ctx)
{

      static long my_static_var;

      if (global_flag)

              my_static_var++;

      else

              data.x += param1;

      return 0;
}
```

$ cat example2.bpf.c

```
#include <linux/ptrace.h>
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
struct {

      __uint(type, BPF_MAP_TYPE_HASH);

      __uint(max_entries, 128);

      __type(key, int);

      __type(value, long);
} my_map SEC(".maps");
SEC("raw_tp/sys_exit")
int handle_sys_exit(struct pt_regs *ctx)
{

      int zero = 0;

      bpf_map_lookup_elem(&my_map, &zero);

      return 0;
}
```

$ cat example3.bpf.c

```
#include <linux/ptrace.h>
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
/* This header file is provided by the bpf_testmod module. */
#include "bpf_testmod.h"
int test_2_result = 0;
/* bpf_Testmod.ko calls this function, passing a "4"

 * and testmod_map->data.

 */
SEC("struct_ops/test_2")
void BPF_PROG(test_2, int a, int b)
{

      test_2_result = a + b;
}
SEC(".struct_ops")
struct bpf_testmod_ops testmod_map = {

      .test_2 = (void *)test_2,

      .data = 0x1,
};
```

This is example BPF application with three BPF programs and a mix of BPF maps and global variables. Source code is split across three source code files.

$ clang --target=bpf -g example1.bpf.c -o example1.bpf.o

$ clang --target=bpf -g example2.bpf.c -o example2.bpf.o

$ clang --target=bpf -g example3.bpf.c -o example3.bpf.o

$ bpftool gen object example.bpf.o example1.bpf.o example2.bpf.o example3.bpf.o

This set of commands compiles example1.bpf.c, example2.bpf.c and example3.bpf.c individually and then statically links respective object files into the final BPF ELF object file example.bpf.o.

$ bpftool gen skeleton example.bpf.o name example | tee example.skel.h

```
/* SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) */
/* THIS FILE IS AUTOGENERATED! */
#ifndef __EXAMPLE_SKEL_H__
#define __EXAMPLE_SKEL_H__
#include <stdlib.h>
#include <bpf/libbpf.h>
struct example {

      struct bpf_object_skeleton *skeleton;

      struct bpf_object *obj;

      struct {

              struct bpf_map *rodata;

              struct bpf_map *data;

              struct bpf_map *bss;

              struct bpf_map *my_map;

              struct bpf_map *testmod_map;

      } maps;

      struct {

              struct example__testmod_map__bpf_testmod_ops {

                      const struct bpf_program *test_1;

                      const struct bpf_program *test_2;

                      int data;

              } *testmod_map;

      } struct_ops;

      struct {

              struct bpf_program *handle_sys_enter;

              struct bpf_program *handle_sys_exit;

      } progs;

      struct {

              struct bpf_link *handle_sys_enter;

              struct bpf_link *handle_sys_exit;

      } links;

      struct example__bss {

              struct {

                      int x;

              } data;

              int test_2_result;

      } *bss;

      struct example__data {

              _Bool global_flag;

              long int handle_sys_enter_my_static_var;

      } *data;

      struct example__rodata {

              int param1;

      } *rodata;
};
static void example__destroy(struct example *obj);
static inline struct example *example__open_opts(

              const struct bpf_object_open_opts *opts);
static inline struct example *example__open();
static inline int example__load(struct example *obj);
static inline struct example *example__open_and_load();
static inline int example__attach(struct example *obj);
static inline void example__detach(struct example *obj);
#endif /* __EXAMPLE_SKEL_H__ */
```

$ cat example.c

```
#include "example.skel.h"
int main()
{

      struct example *skel;

      int err = 0;

      skel = example__open();

      if (!skel)

              goto cleanup;

      skel->rodata->param1 = 128;

      /* Change the value through the pointer of shadow type */

      skel->struct_ops.testmod_map->data = 13;

      err = example__load(skel);

      if (err)

              goto cleanup;

      /* The result of the function test_2() */

      printf("test_2_result: %d\n", skel->bss->test_2_result);

      err = example__attach(skel);

      if (err)

              goto cleanup;

      /* all libbpf APIs are usable */

      printf("my_map name: %s\n", bpf_map__name(skel->maps.my_map));

      printf("sys_enter prog FD: %d\n",

             bpf_program__fd(skel->progs.handle_sys_enter));

      /* detach and re-attach sys_exit program */

      bpf_link__destroy(skel->links.handle_sys_exit);

      skel->links.handle_sys_exit =

              bpf_program__attach(skel->progs.handle_sys_exit);

      printf("my_static_var: %ld\n",

             skel->bss->handle_sys_enter_my_static_var);
cleanup:

      example__destroy(skel);

      return err;
}
```

\# ./example

```
test_2_result: 17
my_map name: my_map
sys_enter prog FD: 8
my_static_var: 7
```

This is a stripped-out version of skeleton generated for above example code.

### min_core_btf
$ bpftool btf dump file 5.4.0-example.btf format raw

```
[1] INT 'long unsigned int' size=8 bits_offset=0 nr_bits=64 encoding=(none)
[2] CONST '(anon)' type_id=1
[3] VOLATILE '(anon)' type_id=1
[4] ARRAY '(anon)' type_id=1 index_type_id=21 nr_elems=2
[5] PTR '(anon)' type_id=8
[6] CONST '(anon)' type_id=5
[7] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=(none)
[8] CONST '(anon)' type_id=7
[9] INT 'unsigned int' size=4 bits_offset=0 nr_bits=32 encoding=(none)
<long output>
```

$ bpftool btf dump file one.bpf.o format raw

```
[1] PTR '(anon)' type_id=2
[2] STRUCT 'trace_event_raw_sys_enter' size=64 vlen=4

      'ent' type_id=3 bits_offset=0

      'id' type_id=7 bits_offset=64

      'args' type_id=9 bits_offset=128

      '__data' type_id=12 bits_offset=512
[3] STRUCT 'trace_entry' size=8 vlen=4

      'type' type_id=4 bits_offset=0

      'flags' type_id=5 bits_offset=16

      'preempt_count' type_id=5 bits_offset=24
<long output>
```

$ bpftool gen min_core_btf 5.4.0-example.btf 5.4.0-smaller.btf one.bpf.o

$ bpftool btf dump file 5.4.0-smaller.btf format raw

```
[1] TYPEDEF 'pid_t' type_id=6
[2] STRUCT 'trace_event_raw_sys_enter' size=64 vlen=1

      'args' type_id=4 bits_offset=128
[3] STRUCT 'task_struct' size=9216 vlen=2

      'pid' type_id=1 bits_offset=17920

      'real_parent' type_id=7 bits_offset=18048
[4] ARRAY '(anon)' type_id=5 index_type_id=8 nr_elems=6
[5] INT 'long unsigned int' size=8 bits_offset=0 nr_bits=64 encoding=(none)
[6] TYPEDEF '__kernel_pid_t' type_id=8
[7] PTR '(anon)' type_id=3
[8] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
<end>
```

Now, the "5.4.0-smaller.btf" file may be used by libbpf as an external BTF file when loading the "one.bpf.o" object into the "5.4.0-example" kernel. Note that the generated BTF file won't allow other eBPF objects to be loaded, just the ones given to min_core_btf.

```
LIBBPF_OPTS(bpf_object_open_opts, opts, .btf_custom_path = "5.4.0-smaller.btf");
struct bpf_object *obj;
obj = bpf_object__open_file("one.bpf.o", &opts);
...
```

## SEE ALSO
bpf(2), bpf-helpers(7), bpftool(8), bpftool-btf(8), bpftool-cgroup(8), bpftool-feature(8), bpftool-iter(8), bpftool-link(8), bpftool-map(8), bpftool-net(8), bpftool-perf(8), bpftool-prog(8), bpftool-struct_ops(8), bpftool-token(8)


bpftool-iter

title: bpftool-iter(8)

summary: tool to create BPF iterators

text:
# bpftool-iter(8)

## Name
bpftool-iter - tool to create BPF iterators

## SYNOPSIS
bpftool [OPTIONS] iter COMMAND

OPTIONS := { { -j | --json } [{ -p | --pretty }] | { -d | --debug } }

COMMANDS := { pin | help }

## ITER COMMANDS

```
bpftool iter pin OBJ PATH [map MAP]
bpftool iter help
OBJ := /a/file/of/bpf_iter_target.o
MAP := { id MAP_ID | pinned FILE }
```

## DESCRIPTION
bpftool iter pin OBJ PATH [map MAP]

A bpf iterator combines a kernel iterating of particular kernel data (e.g., tasks, bpf_maps, etc.) and a bpf program called for each kernel data object (e.g., one task, one bpf_map, etc.). User space can read kernel iterator output through read() syscall. The pin command creates a bpf iterator from OBJ, and pin it to PATH. The PATH should be located in bpffs mount. It must not contain a dot character ('.'), which is reserved for future extensions of bpffs.

Map element bpf iterator requires an additional parameter MAP so bpf program can iterate over map elements for that map. User can have a bpf program in kernel to run with each map element, do checking, filtering, aggregation, etc. without copying data to user space.

User can then cat PATH to see the bpf iterator output.

bpftool iter help

Print short help message.

## OPTIONS
-h, --help

Print short help message (similar to bpftool help).

-V, --version

Print bpftool's version number (similar to bpftool version), the number of the libbpf version in use, and optional features that were included when bpftool was compiled. Optional features include linking against LLVM or libbfd to provide the disassembler for JIT-ted programs (bpftool prog dump jited) and usage of BPF skeletons (some features like bpftool prog profile or showing pids associated to BPF objects may rely on it).

-j, --json

Generate JSON output. For commands that cannot produce JSON, this option has no effect.

-p, --pretty

Generate human-readable JSON output. Implies -j.

-d, --debug

Print all logs available, even debug-level information. This includes logs from libbpf as well as from the verifier, when attempting to load programs.

## EXAMPLES
\# bpftool iter pin bpf_iter_netlink.o /sys/fs/bpf/my_netlink

```
Create a file-based bpf iterator from bpf_iter_netlink.o and pin it
to /sys/fs/bpf/my_netlink
```

\# bpftool iter pin bpf_iter_hashmap.o /sys/fs/bpf/my_hashmap map id 20

```
Create a file-based bpf iterator from bpf_iter_hashmap.o and map with
id 20, and pin it to /sys/fs/bpf/my_hashmap
```

## SEE ALSO
bpf(2), bpf-helpers(7), bpftool(8), bpftool-btf(8), bpftool-cgroup(8), bpftool-feature(8), bpftool-gen(8), bpftool-link(8), bpftool-map(8), bpftool-net(8), bpftool-perf(8), bpftool-prog(8), bpftool-struct_ops(8), bpftool-token(8)


bpftool-link

title: bpftool-link(8)

text:
# bpftool-link(8)

## Name
bpftool-link - tool for inspection and simple manipulation of eBPF links

## SYNOPSIS
bpftool [OPTIONS] link COMMAND

OPTIONS := { { -j | --json } [{ -p | --pretty }] | { -d | --debug } | { -f | --bpffs } | { -n | --nomount } }

COMMANDS := { show | list | pin | help }

## LINK COMMANDS

```
bpftool link { show | list } [LINK]
bpftool link pin LINK FILE
bpftool link detach LINK
bpftool link help
LINK := { id LINK_ID | pinned FILE }
```

## DESCRIPTION
bpftool link { show | list } [LINK]

Show information about active links. If LINK is specified show information only about given link, otherwise list all links currently active on the system. Output will start with link ID followed by link type and zero or more named attributes, some of which depend on type of link.

Since Linux 5.8 bpftool is able to discover information about processes that hold open file descriptors (FDs) against BPF links. On such kernels bpftool will automatically emit this information as well.

bpftool link pin LINK FILE

Pin link LINK as FILE. Note: FILE must be located in bpffs mount. It must not contain a dot character ('.'), which is reserved for future extensions of bpffs.

bpftool link detach LINK

Force-detach link LINK. BPF link and its underlying BPF program will stay valid, but they will be detached from the respective BPF hook and BPF link will transition into a defunct state until last open file descriptor for that link is closed.

bpftool link help

Print short help message.

## OPTIONS
-h, --help

Print short help message (similar to bpftool help).

-V, --version

Print bpftool's version number (similar to bpftool version), the number of the libbpf version in use, and optional features that were included when bpftool was compiled. Optional features include linking against LLVM or libbfd to provide the disassembler for JIT-ted programs (bpftool prog dump jited) and usage of BPF skeletons (some features like bpftool prog profile or showing pids associated to BPF objects may rely on it).

-j, --json

Generate JSON output. For commands that cannot produce JSON, this option has no effect.

-p, --pretty

Generate human-readable JSON output. Implies -j.

-d, --debug

Print all logs available, even debug-level information. This includes logs from libbpf as well as from the verifier, when attempting to load programs.

-f, --bpffs

When showing BPF links, show file names of pinned links.

-n, --nomount

Do not automatically attempt to mount any virtual file system (such as tracefs or BPF virtual file system) when necessary.

## EXAMPLES
\# bpftool link show

```
10: cgroup  prog 25

        cgroup_id 614  attach_type egress

        pids test_progs(223)
```

\# bpftool --json --pretty link show

```
[{

        "type": "cgroup",

        "prog_id": 25,

        "cgroup_id": 614,

        "attach_type": "egress",

        "pids": [{

                "pid": 223,

                "comm": "test_progs"

            }

        ]

    }
]
```

```
# bpftool link pin id 10 /sys/fs/bpf/link
# ls -l /sys/fs/bpf/
```

```
-rw------- 1 root root 0 Apr 23 21:39 link
```

## SEE ALSO
bpf(2), bpf-helpers(7), bpftool(8), bpftool-btf(8), bpftool-cgroup(8), bpftool-feature(8), bpftool-gen(8), bpftool-iter(8), bpftool-map(8), bpftool-net(8), bpftool-perf(8), bpftool-prog(8), bpftool-struct_ops(8), bpftool-token(8)


bpftool-map

title: bpftool-map(8)

text:
# bpftool-map(8)

## Name
bpftool-map - tool for inspection and simple manipulation of eBPF maps

## SYNOPSIS
bpftool [OPTIONS] map COMMAND

OPTIONS := { { -j | --json } [{ -p | --pretty }] | { -d | --debug } | { -f | --bpffs } | { -n | --nomount } }

COMMANDS := { show | list | create | dump | update | lookup | getnext | delete | pin | help }

## MAP COMMANDS

```
bpftool map { show | list }   [MAP]
bpftool map create     FILE type TYPE key KEY_SIZE value VALUE_SIZE

entries MAX_ENTRIES name NAME [flags FLAGS] [inner_map MAP]
[offload_dev NAME]

bpftool map dump       MAP
bpftool map update     MAP [key DATA] [value VALUE] [UPDATE_FLAGS]
bpftool map lookup     MAP [key DATA]
bpftool map getnext    MAP [key DATA]
bpftool map delete     MAP  key DATA
bpftool map pin        MAP  FILE
bpftool map event_pipe MAP [cpu N index M]
bpftool map peek       MAP
bpftool map push       MAP value VALUE
bpftool map pop        MAP
bpftool map enqueue    MAP value VALUE
bpftool map dequeue    MAP
bpftool map freeze     MAP
bpftool map help
MAP := { id MAP_ID | pinned FILE | name MAP_NAME }
DATA := { [hex] BYTES }
PROG := { id PROG_ID | pinned FILE | tag PROG_TAG | name PROG_NAME }
VALUE := { DATA | MAP | PROG }
UPDATE_FLAGS := { any | exist | noexist }
TYPE := { hash | array | prog_array | perf_event_array | percpu_hash

| percpu_array | stack_trace | cgroup_array | lru_hash
| lru_percpu_hash | lpm_trie | array_of_maps | hash_of_maps
| devmap | devmap_hash | sockmap | cpumap | xskmap | sockhash
| cgroup_storage | reuseport_sockarray | percpu_cgroup_storage
| queue | stack | sk_storage | struct_ops | ringbuf | inode_storage
| task_storage | bloom_filter | user_ringbuf | cgrp_storage | arena
| insn_array }
```

## DESCRIPTION
bpftool map { show | list } [MAP]

Show information about loaded maps. If MAP is specified show information only about given maps, otherwise list all maps currently loaded on the system. In case of name, MAP may match several maps which will all be shown. Output will start with map ID followed by map type and zero or more named attributes (depending on kernel version).

Since Linux 5.8 bpftool is able to discover information about processes that hold open file descriptors (FDs) against BPF maps. On such kernels bpftool will automatically emit this information as well.

bpftool map create FILE type TYPE key KEY_SIZE value VALUE_SIZE entries MAX_ENTRIES name NAME [flags FLAGS] [inner_map MAP] [offload_dev NAME]

Create a new map with given parameters and pin it to bpffs as FILE. FLAGS should be an integer which is the combination of desired flags, e.g. 1024 for BPF_F_MMAPABLE (see bpf.h UAPI header for existing flags).

To create maps of type array-of-maps or hash-of-maps, the inner_map keyword must be used to pass an inner map. The kernel needs it to collect metadata related to the inner maps that the new map will work with.

Keyword offload_dev expects a network interface name, and is used to request hardware offload for the map.

bpftool map dump MAP

Dump all entries in a given MAP. In case of name, MAP may match several maps which will all be dumped.

bpftool map update MAP [key DATA] [value VALUE] [UPDATE_FLAGS]

Update map entry for a given KEY. UPDATE_FLAGS can be one of: any update existing entry or add if doesn't exit; exist update only if entry already exists; noexist update only if entry doesn't exist.

If the hex keyword is provided in front of the bytes sequence, the bytes are parsed as hexadecimal values, even if no "0x" prefix is added. If the keyword is not provided, then the bytes are parsed as decimal values, unless a "0x" prefix (for hexadecimal) or a "0" prefix (for octal) is provided.

bpftool map lookup MAP [key DATA]

Lookup key in the map.

bpftool map getnext MAP [key DATA]

Get next key. If key is not specified, get first key.

bpftool map delete MAP key DATA

Remove entry from the map.

bpftool map pin MAP FILE

Pin map MAP as FILE. Note: FILE must be located in bpffs mount. It must not contain a dot character ('.'), which is reserved for future extensions of bpffs.

bpftool map event_pipe MAP [cpu N index M]

Read events from a BPF_MAP_TYPE_PERF_EVENT_ARRAY map. Install perf rings into a perf event array map and dump output of any bpf_perf_event_output() call in the kernel. By default read the number of CPUs on the system and install perf ring for each CPU in the corresponding index in the array.

If cpu and index are specified, install perf ring for given cpu at index in the array (single ring).

Note that installing a perf ring into an array will silently replace any existing ring. Any other application will stop receiving events if it installed its rings earlier.

bpftool map peek MAP

Peek next value in the queue or stack.

bpftool map push MAP value VALUE

Push VALUE onto the stack.

bpftool map pop MAP

Pop and print value from the stack.

bpftool map enqueue MAP value VALUE

Enqueue VALUE into the queue.

bpftool map dequeue MAP

Dequeue and print value from the queue.

bpftool map freeze MAP

Freeze the map as read-only from user space. Entries from a frozen map can not longer be updated or deleted with the bpf() system call. This operation is not reversible, and the map remains immutable from user space until its destruction. However, read and write permissions for BPF programs to the map remain unchanged.

bpftool map help

Print short help message.

## OPTIONS
-h, --help

Print short help message (similar to bpftool help).

-V, --version

Print bpftool's version number (similar to bpftool version), the number of the libbpf version in use, and optional features that were included when bpftool was compiled. Optional features include linking against LLVM or libbfd to provide the disassembler for JIT-ted programs (bpftool prog dump jited) and usage of BPF skeletons (some features like bpftool prog profile or showing pids associated to BPF objects may rely on it).

-j, --json

Generate JSON output. For commands that cannot produce JSON, this option has no effect.

-p, --pretty

Generate human-readable JSON output. Implies -j.

-d, --debug

Print all logs available, even debug-level information. This includes logs from libbpf as well as from the verifier, when attempting to load programs.

-f, --bpffs

Show file names of pinned maps.

-n, --nomount

Do not automatically attempt to mount any virtual file system (such as tracefs or BPF virtual file system) when necessary.

## EXAMPLES
\# bpftool map show

```
10: hash  name some_map  flags 0x0

      key 4B  value 8B  max_entries 2048  memlock 167936B

      pids systemd(1)
```

The following three commands are equivalent:

```
# bpftool map update id 10 key hex   20   c4   b7   00 value hex   0f   ff   ff   ab   01   02   03   4c
# bpftool map update id 10 key     0x20 0xc4 0xb7 0x00 value     0x0f 0xff 0xff 0xab 0x01 0x02 0x03 0x4c
# bpftool map update id 10 key       32  196  183    0 value       15  255  255  171    1    2    3   76
```

\# bpftool map lookup id 10 key 0 1 2 3

```
key: 00 01 02 03 value: 00 01 02 03 04 05 06 07
```

\# bpftool map dump id 10

```
key: 00 01 02 03  value: 00 01 02 03 04 05 06 07
key: 0d 00 07 00  value: 02 00 00 00 01 02 03 04
Found 2 elements
```

\# bpftool map getnext id 10 key 0 1 2 3

```
key:
00 01 02 03
next key:
0d 00 07 00
```

```
# mount -t bpf none /sys/fs/bpf/
# bpftool map pin id 10 /sys/fs/bpf/map
# bpftool map del pinned /sys/fs/bpf/map key 13 00 07 00
```

Note that map update can also be used in order to change the program references hold by a program array map. This can be used, for example, to change the programs used for tail-call jumps at runtime, without having to reload the entry-point program. Below is an example for this use case: we load a program defining a prog array map, and with a main function that contains a tail call to other programs that can be used either to "process" packets or to "debug" processing. Note that the prog array map MUST be pinned into the BPF virtual file system for the map update to work successfully, as kernel flushes prog array maps when they have no more references from user space (and the update would be lost as soon as bpftool exits).

```
# bpftool prog loadall tail_calls.o /sys/fs/bpf/foo type xdp
# bpftool prog --bpffs
```

```
545: xdp  name main_func  tag 674b4b5597193dc3  gpl

        loaded_at 2018-12-12T15:02:58+0000  uid 0

        xlated 240B  jited 257B  memlock 4096B  map_ids 294

        pinned /sys/fs/bpf/foo/xdp
546: xdp  name bpf_func_process  tag e369a529024751fc  gpl

        loaded_at 2018-12-12T15:02:58+0000  uid 0

        xlated 200B  jited 164B  memlock 4096B

        pinned /sys/fs/bpf/foo/process
547: xdp  name bpf_func_debug  tag 0b597868bc7f0976  gpl

        loaded_at 2018-12-12T15:02:58+0000  uid 0

        xlated 200B  jited 164B  memlock 4096B

        pinned /sys/fs/bpf/foo/debug
```

\# bpftool map

```
294: prog_array  name jmp_table  flags 0x0

        key 4B  value 4B  max_entries 1  memlock 4096B

        owner_prog_type xdp  owner jited
```

```
# bpftool map pin id 294 /sys/fs/bpf/bar
# bpftool map dump pinned /sys/fs/bpf/bar
```

```
Found 0 elements
```

```
# bpftool map update pinned /sys/fs/bpf/bar key 0 0 0 0 value pinned /sys/fs/bpf/foo/debug
# bpftool map dump pinned /sys/fs/bpf/bar
```

```
key: 00 00 00 00  value: 22 02 00 00
Found 1 element
```

## SEE ALSO
bpf(2), bpf-helpers(7), bpftool(8), bpftool-btf(8), bpftool-cgroup(8), bpftool-feature(8), bpftool-gen(8), bpftool-iter(8), bpftool-link(8), bpftool-net(8), bpftool-perf(8), bpftool-prog(8), bpftool-struct_ops(8), bpftool-token(8)


bpftool-net

title: bpftool-net(8)

text:
# bpftool-net(8)

## Name
bpftool-net - tool for inspection of networking related bpf prog attachments

## SYNOPSIS
bpftool [OPTIONS] net COMMAND

OPTIONS := { { -j | --json } [{ -p | --pretty }] | { -d | --debug } }

COMMANDS := { show | list | attach | detach | help }

## NET COMMANDS

```
bpftool net { show | list } [ dev NAME ]
bpftool net attach ATTACH_TYPE PROG dev NAME [ overwrite ]
bpftool net detach ATTACH_TYPE dev NAME
bpftool net help
PROG := { id PROG_ID | pinned FILE | tag PROG_TAG | name PROG_NAME }
ATTACH_TYPE := { xdp | xdpgeneric | xdpdrv | xdpoffload | tcx_ingress | tcx_egress }
```

## DESCRIPTION
bpftool net { show | list } [ dev NAME ]

List bpf program attachments in the kernel networking subsystem. Currently, device driver xdp attachments, tcx, netkit and old-style tc classifier/action attachments, flow_dissector as well as netfilter attachments are implemented, i.e., for program types BPF_PROG_TYPE_XDP, BPF_PROG_TYPE_SCHED_CLS, BPF_PROG_TYPE_SCHED_ACT, BPF_PROG_TYPE_FLOW_DISSECTOR, BPF_PROG_TYPE_NETFILTER.

For programs attached to a particular cgroup, e.g., BPF_PROG_TYPE_CGROUP_SKB, BPF_PROG_TYPE_CGROUP_SOCK, BPF_PROG_TYPE_SOCK_OPS and BPF_PROG_TYPE_CGROUP_SOCK_ADDR, users can use bpftool cgroup to dump cgroup attachments. For sk_{filter, skb, msg, reuseport} and lwt/seg6 bpf programs, users should consult other tools, e.g., iproute2.

The current output will start with all xdp program attachments, followed by all tcx, netkit, then tc class/qdisc bpf program attachments, then flow_dissector and finally netfilter programs. Both xdp programs and tcx/netkit/tc programs are ordered based on ifindex number. If multiple bpf programs attached to the same networking device through tc, the order will be first all bpf programs attached to tcx, netkit, then tc classes, then all bpf programs attached to non clsact qdiscs, and finally all bpf programs attached to root and clsact qdisc.

bpftool net attach ATTACH_TYPE PROG dev NAME [ overwrite ]

Attach bpf program PROG to network interface NAME with type specified by ATTACH_TYPE. Previously attached bpf program can be replaced by the command used with overwrite option. Currently, only XDP-related modes are supported for ATTACH_TYPE. ATTACH_TYPE can be of: xdp - try native XDP and fallback to generic XDP if NIC driver does not support it; xdpgeneric - Generic XDP. runs at generic XDP hook when packet already enters receive path as skb; xdpdrv - Native XDP. runs earliest point in driver's receive path; xdpoffload - Offload XDP. runs directly on NIC on each packet reception; tcx_ingress - Ingress TCX. runs on ingress net traffic; tcx_egress - Egress TCX. runs on egress net traffic;

bpftool net detach ATTACH_TYPE dev NAME

Detach bpf program attached to network interface NAME with type specified by ATTACH_TYPE. To detach bpf program, same ATTACH_TYPE previously used for attach must be specified. Currently, only XDP-related modes are supported for ATTACH_TYPE.

bpftool net help

Print short help message.

## OPTIONS
-h, --help

Print short help message (similar to bpftool help).

-V, --version

Print bpftool's version number (similar to bpftool version), the number of the libbpf version in use, and optional features that were included when bpftool was compiled. Optional features include linking against LLVM or libbfd to provide the disassembler for JIT-ted programs (bpftool prog dump jited) and usage of BPF skeletons (some features like bpftool prog profile or showing pids associated to BPF objects may rely on it).

-j, --json

Generate JSON output. For commands that cannot produce JSON, this option has no effect.

-p, --pretty

Generate human-readable JSON output. Implies -j.

-d, --debug

Print all logs available, even debug-level information. This includes logs from libbpf as well as from the verifier, when attempting to load programs.

## EXAMPLES

```
# bpftool net
```

```
xdp:
eth0(2) driver id 198
tc:
eth0(2) htb name prefix_matcher.o:[cls_prefix_matcher_htb] id 111727 act []
eth0(2) clsact/ingress fbflow_icmp id 130246 act []
eth0(2) clsact/egress prefix_matcher.o:[cls_prefix_matcher_clsact] id 111726
eth0(2) clsact/egress cls_fg_dscp id 108619 act []
eth0(2) clsact/egress fbflow_egress id 130245
```

```
# bpftool -jp net
```

```
[{

        "xdp": [{

                "devname": "eth0",

                "ifindex": 2,

                "mode": "driver",

                "id": 198

            }

        ],

        "tc": [{

                "devname": "eth0",

                "ifindex": 2,

                "kind": "htb",

                "name": "prefix_matcher.o:[cls_prefix_matcher_htb]",

                "id": 111727,

                "act": []

            },{

                "devname": "eth0",

                "ifindex": 2,

                "kind": "clsact/ingress",

                "name": "fbflow_icmp",

                "id": 130246,

                "act": []

            },{

                "devname": "eth0",

                "ifindex": 2,

                "kind": "clsact/egress",

                "name": "prefix_matcher.o:[cls_prefix_matcher_clsact]",

                "id": 111726,

            },{

                "devname": "eth0",

                "ifindex": 2,

                "kind": "clsact/egress",

                "name": "cls_fg_dscp",

                "id": 108619,

                "act": []

            },{

                "devname": "eth0",

                "ifindex": 2,

                "kind": "clsact/egress",

                "name": "fbflow_egress",

                "id": 130245,

            }

        ]

    }
]
```

```
# bpftool net attach xdpdrv id 16 dev enp6s0np0
# bpftool net
```

```
xdp:
enp6s0np0(4) driver id 16
```

```
# bpftool net attach xdpdrv id 16 dev enp6s0np0
# bpftool net attach xdpdrv id 20 dev enp6s0np0 overwrite
# bpftool net
```

```
xdp:
enp6s0np0(4) driver id 20
```

```
# bpftool net attach xdpdrv id 16 dev enp6s0np0
# bpftool net detach xdpdrv dev enp6s0np0
# bpftool net
```

```
xdp:
```

```
# bpftool net attach tcx_ingress name tc_prog dev lo
# bpftool net
```

```
tc:
lo(1) tcx/ingress tc_prog prog_id 29
```

```
# bpftool net attach tcx_ingress name tc_prog dev lo
# bpftool net detach tcx_ingress dev lo
# bpftool net
```

```
tc:
```

## SEE ALSO
bpf(2), bpf-helpers(7), bpftool(8), bpftool-btf(8), bpftool-cgroup(8), bpftool-feature(8), bpftool-gen(8), bpftool-iter(8), bpftool-link(8), bpftool-map(8), bpftool-perf(8), bpftool-prog(8), bpftool-struct_ops(8), bpftool-token(8)


bpftool-perf

title: bpftool-perf(8)

text:
# bpftool-perf(8)

## Name
bpftool-perf - tool for inspection of perf related bpf prog attachments

## SYNOPSIS
bpftool [OPTIONS] perf COMMAND

OPTIONS := { { -j | --json } [{ -p | --pretty }] | { -d | --debug } }

COMMANDS := { show | list | help }

## PERF COMMANDS

```
bpftool perf { show | list }
bpftool perf help
```

## DESCRIPTION
bpftool perf { show | list }

List all raw_tracepoint, tracepoint, kprobe attachment in the system. Output will start with process id and file descriptor in that process, followed by bpf program id, attachment information, and attachment point. The attachment point for raw_tracepoint/tracepoint is the trace probe name. The attachment point for k[ret]probe is either symbol name and offset, or a kernel virtual address. The attachment point for u[ret]probe is the file name and the file offset.

bpftool perf help

Print short help message.

## OPTIONS
-h, --help

Print short help message (similar to bpftool help).

-V, --version

Print bpftool's version number (similar to bpftool version), the number of the libbpf version in use, and optional features that were included when bpftool was compiled. Optional features include linking against LLVM or libbfd to provide the disassembler for JIT-ted programs (bpftool prog dump jited) and usage of BPF skeletons (some features like bpftool prog profile or showing pids associated to BPF objects may rely on it).

-j, --json

Generate JSON output. For commands that cannot produce JSON, this option has no effect.

-p, --pretty

Generate human-readable JSON output. Implies -j.

-d, --debug

Print all logs available, even debug-level information. This includes logs from libbpf as well as from the verifier, when attempting to load programs.

## EXAMPLES

```
# bpftool perf
```

```
pid 21711  fd 5: prog_id 5  kprobe  func __x64_sys_write  offset 0
pid 21765  fd 5: prog_id 7  kretprobe  func __x64_sys_nanosleep  offset 0
pid 21767  fd 5: prog_id 8  tracepoint  sys_enter_nanosleep
pid 21800  fd 5: prog_id 9  uprobe  filename /home/yhs/a.out  offset 1159
```

```
# bpftool -j perf
```

```
[{"pid":21711,"fd":5,"prog_id":5,"fd_type":"kprobe","func":"__x64_sys_write","offset":0}, \

 {"pid":21765,"fd":5,"prog_id":7,"fd_type":"kretprobe","func":"__x64_sys_nanosleep","offset":0}, \

 {"pid":21767,"fd":5,"prog_id":8,"fd_type":"tracepoint","tracepoint":"sys_enter_nanosleep"}, \

 {"pid":21800,"fd":5,"prog_id":9,"fd_type":"uprobe","filename":"/home/yhs/a.out","offset":1159}]
```

## SEE ALSO
bpf(2), bpf-helpers(7), bpftool(8), bpftool-btf(8), bpftool-cgroup(8), bpftool-feature(8), bpftool-gen(8), bpftool-iter(8), bpftool-link(8), bpftool-map(8), bpftool-net(8), bpftool-prog(8), bpftool-struct_ops(8), bpftool-token(8)


bpftool-prog

title: bpftool-prog(8)

text:
# bpftool-prog(8)

## Name
bpftool-prog - tool for inspection and simple manipulation of eBPF progs

## SYNOPSIS
bpftool [OPTIONS] prog COMMAND

OPTIONS := { { -j | --json } [{ -p | --pretty }] | { -d | --debug } | { -f | --bpffs } | { -m | --mapcompat } | { -n | --nomount } | { -L | --use-loader } | [ { -S | --sign } -k <private_key.pem> -i <certificate.x509> ] }

COMMANDS := { show | list | dump xlated | dump jited | pin | load | loadall | help }

## PROG COMMANDS

```
bpftool prog { show | list } [PROG]
bpftool prog dump xlated PROG [{ file FILE | [opcodes] [linum] [visual] }]
bpftool prog dump jited  PROG [{ file FILE | [opcodes] [linum] }]
bpftool prog pin PROG FILE
bpftool prog { load | loadall } OBJ PATH [type TYPE] [map { idx IDX | name NAME } MAP] [{ offload_dev | xdpmeta_dev } NAME] [pinmaps MAP_DIR] [autoattach] [kernel_btf BTF_FILE]
bpftool prog attach PROG ATTACH_TYPE [MAP]
bpftool prog detach PROG ATTACH_TYPE [MAP]
bpftool prog tracelog
bpftool prog tracelog [ { stdout | stderr  } PROG ]
bpftool prog run PROG data_in FILE [data_out FILE [data_size_out L]] [ctx_in FILE [ctx_out FILE [ctx_size_out M]]] [repeat N]
bpftool prog profile PROG [duration DURATION] METRICs
bpftool prog help
MAP := { id MAP_ID | pinned FILE | name MAP_NAME }
PROG := { id PROG_ID | pinned FILE | tag PROG_TAG | name PROG_NAME }
TYPE := {

socket | kprobe | kretprobe | classifier | action |
tracepoint | raw_tracepoint | xdp | perf_event | cgroup/skb |
cgroup/sock | cgroup/dev | lwt_in | lwt_out | lwt_xmit |
lwt_seg6local | sockops | sk_skb | sk_msg | lirc_mode2 |
cgroup/bind4 | cgroup/bind6 | cgroup/post_bind4 | cgroup/post_bind6 |
cgroup/connect4 | cgroup/connect6 | cgroup/connect_unix |
cgroup/getpeername4 | cgroup/getpeername6 | cgroup/getpeername_unix |
cgroup/getsockname4 | cgroup/getsockname6 | cgroup/getsockname_unix |
cgroup/sendmsg4 | cgroup/sendmsg6 | cgroup/sendmsg_unix |
cgroup/recvmsg4 | cgroup/recvmsg6 | cgroup/recvmsg_unix | cgroup/sysctl |
cgroup/getsockopt | cgroup/setsockopt | cgroup/sock_release |
struct_ops | fentry | fexit | freplace | sk_lookup

}
ATTACH_TYPE := {

sk_msg_verdict | sk_skb_verdict | sk_skb_stream_verdict |
sk_skb_stream_parser | flow_dissector

}
METRICs := {

cycles | instructions | l1d_loads | llc_misses |
itlb_misses | dtlb_misses

}
```

## DESCRIPTION
bpftool prog { show | list } [PROG]

Show information about loaded programs. If PROG is specified show information only about given programs, otherwise list all programs currently loaded on the system. In case of tag or name, PROG may match several programs which will all be shown. Output will start with program ID followed by program type and zero or more named attributes (depending on kernel version).

Since Linux 5.1 the kernel can collect statistics on BPF programs (such as the total time spent running the program, and the number of times it was run). If available, bpftool shows such statistics. However, the kernel does not collect them by defaults, as it slightly impacts performance on each program run. Activation or deactivation of the feature is performed via the kernel.bpf_stats_enabled sysctl knob.

Since Linux 5.8 bpftool is able to discover information about processes that hold open file descriptors (FDs) against BPF programs. On such kernels bpftool will automatically emit this information as well.

bpftool prog dump xlated PROG [{ file FILE | [opcodes] [linum] [visual] }]

Dump eBPF instructions of the programs from the kernel. By default, eBPF will be disassembled and printed to standard output in human-readable format. In this case, opcodes controls if raw opcodes should be printed as well. In case of tag or name, PROG may match several programs which will all be dumped. However, if file or visual is specified, PROG must match a single program.

If file is specified, the binary image will instead be written to FILE.

If visual is specified, control flow graph (CFG) will be built instead, and eBPF instructions will be presented with CFG in DOT format, on standard output.

If the programs have line_info available, the source line will be displayed. If linum is specified, the filename, line number and line column will also be displayed.

bpftool prog dump jited PROG [{ file FILE | [opcodes] [linum] }]

Dump jited image (host machine code) of the program. If FILE is specified image will be written to a file, otherwise it will be disassembled and printed to stdout. PROG must match a single program when file is specified.

opcodes controls if raw opcodes will be printed.

If the prog has line_info available, the source line will be displayed. If linum is specified, the filename, line number and line column will also be displayed.

bpftool prog pin PROG FILE

Pin program PROG as FILE. Note: FILE must be located in bpffs mount. It must not contain a dot character ('.'), which is reserved for future extensions of bpffs.

bpftool prog { load | loadall } OBJ PATH [type TYPE] [map { idx IDX | name NAME } MAP] [{ offload_dev | xdpmeta_dev } NAME] [pinmaps MAP_DIR] [autoattach] [kernel_btf BTF_FILE]

Load bpf program(s) from binary OBJ and pin as PATH. bpftool prog load pins only the first program from the OBJ as PATH. bpftool prog loadall pins all programs from the OBJ under PATH directory. type is optional, if not specified program type will be inferred from section names. By default bpftool will create new maps as declared in the ELF object being loaded. map parameter allows for the reuse of existing maps. It can be specified multiple times, each time for a different map. IDX refers to index of the map to be replaced in the ELF file counting from 0, while NAME allows to replace a map by name. MAP specifies the map to use, referring to it by id or through a pinned file. If offload_dev NAME is specified program will be loaded onto given networking device (offload). If xdpmeta_dev NAME is specified program will become device-bound without offloading, this facilitates access to XDP metadata. Optional pinmaps argument can be provided to pin all maps under MAP_DIR directory. If autoattach is specified program will be attached before pin. In that case, only the link (representing the program attached to its hook) is pinned, not the program as such, so the path won't show in bpftool prog show -f, only show in bpftool link show -f. Also, this only works when bpftool (libbpf) is able to infer all necessary information from the object file, in particular, it's not supported for all program types. If a program does not support autoattach, bpftool falls back to regular pinning for that program instead.

The kernel_btf option allows specifying an external BTF file to replace the system's own vmlinux BTF file for CO-RE relocations. Note that any other feature relying on BTF (such as fentry/fexit programs, struct_ops) requires the BTF file for the actual kernel running on the host, often exposed at /sys/kernel/btf/vmlinux.

Note: PATH must be located in bpffs mount. It must not contain a dot character ('.'), which is reserved for future extensions of bpffs.

bpftool prog attach PROG ATTACH_TYPE [MAP]

Attach bpf program PROG (with type specified by ATTACH_TYPE). Most ATTACH_TYPEs require a MAP parameter, with the exception of flow_dissector which is attached to current networking name space.

bpftool prog detach PROG ATTACH_TYPE [MAP]

Detach bpf program PROG (with type specified by ATTACH_TYPE). Most ATTACH_TYPEs require a MAP parameter, with the exception of flow_dissector which is detached from the current networking name space.

bpftool prog tracelog

Dump the trace pipe of the system to the console (stdout). Hit <Ctrl+C> to stop printing. BPF programs can write to this trace pipe at runtime with the bpf_trace_printk() helper. This should be used only for debugging purposes. For streaming data from BPF programs to user space, one can use perf events (see also bpftool-map(8)).

bpftool prog tracelog { stdout | stderr } PROG

Dump the BPF stream of the program. BPF programs can write to these streams at runtime with the bpf_stream_vprintk_impl() kfunc. The kernel may write error messages to the standard error stream. This facility should be used only for debugging purposes.

bpftool prog run PROG data_in FILE [data_out FILE [data_size_out L]] [ctx_in FILE [ctx_out FILE [ctx_size_out M]]] [repeat N]

Run BPF program PROG in the kernel testing infrastructure for BPF, meaning that the program works on the data and context provided by the user, and not on actual packets or monitored functions etc. Return value and duration for the test run are printed out to the console. Input data is read from the FILE passed with data_in. If this FILE is "-", input data is read from standard input. Input context, if any, is read from FILE passed with ctx_in. Again, "-" can be used to read from standard input, but only if standard input is not already in use for input data. If a FILE is passed with data_out, output data is written to that file. Similarly, output context is written to the FILE passed with ctx_out. For both output flows, "-" can be used to print to the standard output (as plain text, or JSON if relevant option was passed). If output keywords are omitted, output data and context are discarded. Keywords data_size_out and ctx_size_out are used to pass the size (in bytes) for the output buffers to the kernel, although the default of 32 kB should be more than enough for most cases.

Keyword repeat is used to indicate the number of consecutive runs to perform. Note that output data and context printed to files correspond to the last of those runs. The duration printed out at the end of the runs is an average over all runs performed by the command.

Not all program types support test run. Among those which do, not all of them can take the ctx_in/ctx_out arguments. bpftool does not perform checks on program types.

bpftool prog profile PROG [duration DURATION] METRICs

Profile METRICs for bpf program PROG for DURATION seconds or until user hits <Ctrl+C>. DURATION is optional. If DURATION is not specified, the profiling will run up to UINT_MAX seconds.

bpftool prog help

Print short help message.

## OPTIONS
-h, --help

Print short help message (similar to bpftool help).

-V, --version

Print bpftool's version number (similar to bpftool version), the number of the libbpf version in use, and optional features that were included when bpftool was compiled. Optional features include linking against LLVM or libbfd to provide the disassembler for JIT-ted programs (bpftool prog dump jited) and usage of BPF skeletons (some features like bpftool prog profile or showing pids associated to BPF objects may rely on it).

-j, --json

Generate JSON output. For commands that cannot produce JSON, this option has no effect.

-p, --pretty

Generate human-readable JSON output. Implies -j.

-d, --debug

Print all logs available, even debug-level information. This includes logs from libbpf as well as from the verifier, when attempting to load programs.

-f, --bpffs

When showing BPF programs, show file names of pinned programs.

-m, --mapcompat

Allow loading maps with unknown map definitions.

-n, --nomount

Do not automatically attempt to mount any virtual file system (such as tracefs or BPF virtual file system) when necessary.

-L, --use-loader

Load program as a "loader" program. This is useful to debug the generation of such programs. When this option is in use, bpftool attempts to load the programs from the object file into the kernel, but does not pin them (therefore, the PATH must not be provided). When combined with the -d|--debug option, additional debug messages are generated, and the execution of the loader program will use the bpf_trace_printk() helper to log each step of loading BTF, creating the maps, and loading the programs (see bpftool prog tracelog as a way to dump those messages).

-S, --sign

Enable signing of the BPF program before loading. This option must be used with -k and -i. Using this flag implicitly enables --use-loader.

-k <private_key.pem>

Path to the private key file in PEM format, required when signing.

-i <certificate.x509>

Path to the X.509 certificate file in PEM or DER format, required when signing.

## EXAMPLES
\# bpftool prog show

```
10: xdp  name some_prog  tag 005a3d2123620c8b  gpl run_time_ns 81632 run_cnt 10

        loaded_at 2017-09-29T20:11:00+0000  uid 0

        xlated 528B  jited 370B  memlock 4096B  map_ids 10

        pids systemd(1)
```

\# bpftool --json --pretty prog show

```
[{

        "id": 10,

        "type": "xdp",

        "tag": "005a3d2123620c8b",

        "gpl_compatible": true,

        "run_time_ns": 81632,

        "run_cnt": 10,

        "loaded_at": 1506715860,

        "uid": 0,

        "bytes_xlated": 528,

        "jited": true,

        "bytes_jited": 370,

        "bytes_memlock": 4096,

        "map_ids": [10

        ],

        "pids": [{

                "pid": 1,

                "comm": "systemd"

            }

        ]

    }
]
```

```
# bpftool prog dump xlated id 10 file /tmp/t
$ ls -l /tmp/t
```

```
-rw------- 1 root root 560 Jul 22 01:42 /tmp/t
```

\# bpftool prog dump jited tag 005a3d2123620c8b

```
0:   push   %rbp
1:   mov    %rsp,%rbp
2:   sub    $0x228,%rsp
3:   sub    $0x28,%rbp
4:   mov    %rbx,0x0(%rbp)
```

```
# mount -t bpf none /sys/fs/bpf/
# bpftool prog pin id 10 /sys/fs/bpf/prog
# bpftool prog load ./my_prog.o /sys/fs/bpf/prog2
# ls -l /sys/fs/bpf/
```

```
-rw------- 1 root root 0 Jul 22 01:43 prog
-rw------- 1 root root 0 Jul 22 01:44 prog2
```

\# bpftool prog dump jited pinned /sys/fs/bpf/prog opcodes

```
0:   push   %rbp

     55
1:   mov    %rsp,%rbp

     48 89 e5
4:   sub    $0x228,%rsp

     48 81 ec 28 02 00 00
b:   sub    $0x28,%rbp

     48 83 ed 28
f:   mov    %rbx,0x0(%rbp)

     48 89 5d 00
```

```
# bpftool prog load xdp1_kern.o /sys/fs/bpf/xdp1 type xdp map name rxcnt id 7
# bpftool prog show pinned /sys/fs/bpf/xdp1
```

```
9: xdp  name xdp_prog1  tag 539ec6ce11b52f98  gpl

        loaded_at 2018-06-25T16:17:31-0700  uid 0

        xlated 488B  jited 336B  memlock 4096B  map_ids 7
```

\# rm /sys/fs/bpf/xdp1

```
# bpftool prog profile id 337 duration 10 cycles instructions llc_misses
```

```
   51397 run_cnt
40176203 cycles                                                 (83.05%)
42518139 instructions    #   1.06 insns per cycle               (83.39%)

     123 llc_misses      #   2.89 LLC misses per million insns  (83.15%)
```

```
Output below is for the trace logs.
Run in separate terminals:
# bpftool prog tracelog
# bpftool prog load -L -d file.o
```

```
bpftool-620059  [004] d... 2634685.517903: bpf_trace_printk: btf_load size 665 r=5
bpftool-620059  [004] d... 2634685.517912: bpf_trace_printk: map_create sample_map idx 0 type 2 value_size 4 value_btf_id 0 r=6
bpftool-620059  [004] d... 2634685.517997: bpf_trace_printk: prog_load sample insn_cnt 13 r=7
bpftool-620059  [004] d... 2634685.517999: bpf_trace_printk: close(5) = 0
```

## SEE ALSO
bpf(2), bpf-helpers(7), bpftool(8), bpftool-btf(8), bpftool-cgroup(8), bpftool-feature(8), bpftool-gen(8), bpftool-iter(8), bpftool-link(8), bpftool-map(8), bpftool-net(8), bpftool-perf(8), bpftool-struct_ops(8), bpftool-token(8)


title: bpftool-struct_ops(8)

text:
# bpftool-struct_ops(8)

## Name
bpftool-struct_ops - tool to register/unregister/introspect BPF struct_ops

## SYNOPSIS
bpftool [OPTIONS] struct_ops COMMAND

OPTIONS := { { -j | --json } [{ -p | --pretty }] | { -d | --debug } }

COMMANDS := { show | list | dump | register | unregister | help }

## STRUCT_OPS COMMANDS

```
bpftool struct_ops { show | list } [STRUCT_OPS_MAP]
bpftool struct_ops dump [STRUCT_OPS_MAP]
bpftool struct_ops register OBJ [LINK_DIR]
bpftool struct_ops unregister STRUCT_OPS_MAP
bpftool struct_ops help
STRUCT_OPS_MAP := { id STRUCT_OPS_MAP_ID | name STRUCT_OPS_MAP_NAME }
OBJ := /a/file/of/bpf_struct_ops.o
```

## DESCRIPTION
bpftool struct_ops { show | list } [STRUCT_OPS_MAP]

Show brief information about the struct_ops in the system. If STRUCT_OPS_MAP is specified, it shows information only for the given struct_ops. Otherwise, it lists all struct_ops currently existing in the system. Output will start with struct_ops map ID, followed by its map name and its struct_ops's kernel type.

bpftool struct_ops dump [STRUCT_OPS_MAP]

Dump details information about the struct_ops in the system. If STRUCT_OPS_MAP is specified, it dumps information only for the given struct_ops. Otherwise, it dumps all struct_ops currently existing in the system.

bpftool struct_ops register OBJ [LINK_DIR]

Register bpf struct_ops from OBJ. All struct_ops under the ELF section ".struct_ops" and ".struct_ops.link" will be registered to its kernel subsystem. For each struct_ops in the ".struct_ops.link" section, a link will be created. You can give LINK_DIR to provide a directory path where these links will be pinned with the same name as their corresponding map name.

bpftool struct_ops unregister STRUCT_OPS_MAP

Unregister the STRUCT_OPS_MAP from the kernel subsystem.

bpftool struct_ops help

Print short help message.

## OPTIONS
-h, --help

Print short help message (similar to bpftool help).

-V, --version

Print bpftool's version number (similar to bpftool version), the number of the libbpf version in use, and optional features that were included when bpftool was compiled. Optional features include linking against LLVM or libbfd to provide the disassembler for JIT-ted programs (bpftool prog dump jited) and usage of BPF skeletons (some features like bpftool prog profile or showing pids associated to BPF objects may rely on it).

-j, --json

Generate JSON output. For commands that cannot produce JSON, this option has no effect.

-p, --pretty

Generate human-readable JSON output. Implies -j.

-d, --debug

Print all logs available, even debug-level information. This includes logs from libbpf as well as from the verifier, when attempting to load programs.

## EXAMPLES
\# bpftool struct_ops show

```
100: dctcp           tcp_congestion_ops
105: cubic           tcp_congestion_ops
```

\# bpftool struct_ops unregister id 105

```
Unregistered tcp_congestion_ops cubic id 105
```

\# bpftool struct_ops register bpf_cubic.o

```
Registered tcp_congestion_ops cubic id 110
```

## SEE ALSO
bpf(2), bpf-helpers(7), bpftool(8), bpftool-btf(8), bpftool-cgroup(8), bpftool-feature(8), bpftool-gen(8), bpftool-iter(8), bpftool-link(8), bpftool-map(8), bpftool-net(8), bpftool-perf(8), bpftool-prog(8), bpftool-token(8)


bpftool-token

title: bpftool-token(8)

text:
# bpftool-token(8)

## Name
bpftool-token - tool for inspection and simple manipulation of eBPF tokens

## SYNOPSIS
bpftool [OPTIONS] token COMMAND

OPTIONS := { { -j | --json } [{ -p | --pretty }] | { -d | --debug } }

COMMANDS := { show | list | help }

## TOKEN COMMANDS

```
bpftool token { show | list }
bpftool token help
```

## DESCRIPTION
bpftool token { show | list }

List BPF token information for each bpffs mount point containing token information on the system. Information include mount point path, allowed bpf() system call commands, maps, programs, and attach types for the token.

bpftool prog help

Print short help message.

## OPTIONS
-h, --help

Print short help message (similar to bpftool help).

-V, --version

Print bpftool's version number (similar to bpftool version), the number of the libbpf version in use, and optional features that were included when bpftool was compiled. Optional features include linking against LLVM or libbfd to provide the disassembler for JIT-ted programs (bpftool prog dump jited) and usage of BPF skeletons (some features like bpftool prog profile or showing pids associated to BPF objects may rely on it).

-j, --json

Generate JSON output. For commands that cannot produce JSON, this option has no effect.

-p, --pretty

Generate human-readable JSON output. Implies -j.

-d, --debug

Print all logs available, even debug-level information. This includes logs from libbpf as well as from the verifier, when attempting to load programs.

## EXAMPLES

```
# mkdir -p /sys/fs/bpf/token
# mount -t bpf bpffs /sys/fs/bpf/token

-o delegate_cmds=prog_load:map_create
-o delegate_progs=kprobe
-o delegate_attachs=xdp

# bpftool token list
```

```
token_info  /sys/fs/bpf/token

        allowed_cmds:

          map_create          prog_load

        allowed_maps:

        allowed_progs:

          kprobe

        allowed_attachs:

          xdp
```

## SEE ALSO
bpf(2), bpf-helpers(7), bpftool(8), bpftool-btf(8), bpftool-cgroup(8), bpftool-feature(8), bpftool-gen(8), bpftool-iter(8), bpftool-link(8), bpftool-map(8), bpftool-net(8), bpftool-perf(8), bpftool-prog(8), bpftool-struct_ops(8)