#
eed512e8 |
|
07-Mar-2024 |
Alexei Starovoitov <ast@kernel.org> |
bpftool: Recognize arena map type Teach bpftool to recognize arena map type. Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/bpf/20240308010812.89848-10-alexei.starovoitov@gmail.com
|
#
f46392ee |
|
17-May-2023 |
Larysa Zaremba <larysa.zaremba@intel.com> |
bpftool: Specify XDP Hints ifname when loading program Add ability to specify a network interface used to resolve XDP hints kfuncs when loading program through bpftool. Usage: bpftool prog load [...] xdpmeta_dev <ifname> Writing just 'dev <ifname>' instead of 'xdpmeta_dev' is a very probable mistake that results in not very descriptive errors, so 'bpftool prog load [...] dev <ifname>' syntax becomes deprecated, followed by 'bpftool map create [...] dev <ifname>' for consistency. Now, to offload program, execute: bpftool prog load [...] offload_dev <ifname> To offload map: bpftool map create [...] offload_dev <ifname> 'dev <ifname>' still performs offloading in the commands above, but now triggers a warning and is excluded from bash completion. 'xdpmeta_dev' and 'offload_dev' are mutually exclusive options, because 'xdpmeta_dev' basically makes a program device-bound without loading it onto the said device. For now, offloaded programs cannot use XDP hints [0], but if this changes, using 'offload_dev <ifname>' should cover this case. [0] https://lore.kernel.org/bpf/a5a636cc-5b03-686f-4be0-000383b05cfc@linux.dev Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/bpf/20230517160103.1088185-1-larysa.zaremba@intel.com
|
#
bf06c939 |
|
27-Apr-2023 |
Xueming Feng <kuro@kuroa.me> |
bpftool: Dump map id instead of value for map_of_maps types When using `bpftool map dump` with map_of_maps, it is usually more convenient to show the inner map id instead of raw value. We are changing the plain print behavior to show inner_map_id instead of hex value, this would help with quick look up of inner map with `bpftool map dump id <inner_map_id>`. To avoid disrupting scripted behavior, we will add a new `inner_map_id` field to json output instead of replacing value. plain print: ``` $ bpftool map dump id 138 Without Patch: key: fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 27 16 06 00 value: 8b 00 00 00 Found 1 element With Patch: key: fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 27 16 06 00 inner_map_id: 139 Found 1 element ``` json print: ``` $ bpftool -p map dump id 567 Without Patch: [{ "key": ["0xc0","0x00","0x02","0x05","0x27","0x16","0x06","0x00" ], "value": ["0x38","0x02","0x00","0x00" ] } ] With Patch: [{ "key": ["0xc0","0x00","0x02","0x05","0x27","0x16","0x06","0x00" ], "value": ["0x38","0x02","0x00","0x00" ], "inner_map_id": 568 } ] ``` Signed-off-by: Xueming Feng <kuro@kuroa.me> Acked-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/r/20230427120313.43574-1-kuro@kuroa.me Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
|
#
38f0408e |
|
14-Feb-2023 |
Ilya Leoshkevich <iii@linux.ibm.com> |
bpftool: Use bpf_{btf,link,map,prog}_get_info_by_fd() Use the new type-safe wrappers around bpf_obj_get_info_by_fd(). Split the bpf_obj_get_info_by_fd() call in build_btf_type_table() in two, since knowing the type helps with the Memory Sanitizer. Improve map_parse_fd_and_info() type safety by using struct bpf_map_info * instead of void * for info. Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/bpf/20230214231221.249277-4-iii@linux.ibm.com
|
#
52df1a8a |
|
20-Nov-2022 |
Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com> |
bpftool: remove function free_btf_vmlinux() The function contains a single btf__free() call which can be inlined. Credits to Yonghong Song. Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com> Acked-by: Yonghong Song <yhs@fb.com> Suggested-by: Yonghong Song <yhs@fb.com> Reviewed-by: Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/r/20221120112515.38165-6-sahid.ferdjaoui@industrialdiscipline.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
d1313e01 |
|
20-Nov-2022 |
Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com> |
bpftool: clean-up usage of libbpf_get_error() bpftool is now totally compliant with libbpf 1.0 mode and is not expected to be compiled with pre-1.0, let's clean-up the usage of libbpf_get_error(). The changes stay aligned with returned errors always negative. - In tools/bpf/bpftool/btf.c This fixes an uninitialized local variable `err` in function do_dump() because it may now be returned without having been set. - This also removes the checks on NULL pointers before calling btf__free() because that function already does the check. Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com> Link: https://lore.kernel.org/r/20221120112515.38165-5-sahid.ferdjaoui@industrialdiscipline.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
c302378b |
|
09-Nov-2022 |
Eduard Zingerman <eddyz87@gmail.com> |
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
|
#
f7f0f165 |
|
25-Oct-2022 |
Yonghong Song <yhs@fb.com> |
bpftool: Support new cgroup local storage Add support for new cgroup local storage Acked-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/r/20221026042901.674177-1-yhs@fb.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
55b4de58 |
|
25-Oct-2022 |
Quentin Monnet <quentin@isovalent.com> |
bpftool: Remove asserts from JIT disassembler The JIT disassembler in bpftool is the only components (with the JSON writer) using asserts to check the return values of functions. But it does not do so in a consistent way, and diasm_print_insn() returns no value, although sometimes the operation failed. Remove the asserts, and instead check the return values, print messages on errors, and propagate the error to the caller from prog.c. Remove the inclusion of assert.h from jit_disasm.c, and also from map.c where it is unused. Signed-off-by: Quentin Monnet <quentin@isovalent.com> Tested-by: Niklas Söderlund <niklas.soderlund@corigine.com> Acked-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/r/20221025150329.97371-3-quentin@isovalent.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
583c1f42 |
|
19-Sep-2022 |
David Vernet <void@manifault.com> |
bpf: Define new BPF_MAP_TYPE_USER_RINGBUF map type We want to support a ringbuf map type where samples are published from user-space, to be consumed by BPF programs. BPF currently supports a kernel -> user-space circular ring buffer via the BPF_MAP_TYPE_RINGBUF map type. We'll need to define a new map type for user-space -> kernel, as none of the helpers exported for BPF_MAP_TYPE_RINGBUF will apply to a user-space producer ring buffer, and we'll want to add one or more helper functions that would not apply for a kernel-producer ring buffer. This patch therefore adds a new BPF_MAP_TYPE_USER_RINGBUF map type definition. The map type is useless in its current form, as there is no way to access or use it for anything until we one or more BPF helpers. A follow-on patch will therefore add a new helper function that allows BPF programs to run callbacks on samples that are published to the ring buffer. Signed-off-by: David Vernet <void@manifault.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20220920000100.477320-2-void@manifault.com
|
#
6b4384ff |
|
09-Jun-2022 |
Quentin Monnet <quentin@isovalent.com> |
Revert "bpftool: Use libbpf 1.0 API mode instead of RLIMIT_MEMLOCK" This reverts commit a777e18f1bcd32528ff5dfd10a6629b655b05eb8. In commit a777e18f1bcd ("bpftool: Use libbpf 1.0 API mode instead of RLIMIT_MEMLOCK"), we removed the rlimit bump in bpftool, because the kernel has switched to memcg-based memory accounting. Thanks to the LIBBPF_STRICT_AUTO_RLIMIT_MEMLOCK, we attempted to keep compatibility with other systems and ask libbpf to raise the limit for us if necessary. How do we know if memcg-based accounting is supported? There is a probe in libbpf to check this. But this probe currently relies on the availability of a given BPF helper, bpf_ktime_get_coarse_ns(), which landed in the same kernel version as the memory accounting change. This works in the generic case, but it may fail, for example, if the helper function has been backported to an older kernel. This has been observed for Google Cloud's Container-Optimized OS (COS), where the helper is available but rlimit is still in use. The probe succeeds, the rlimit is not raised, and probing features with bpftool, for example, fails. A patch was submitted [0] to update this probe in libbpf, based on what the cilium/ebpf Go library does [1]. It would lower the soft rlimit to 0, attempt to load a BPF object, and reset the rlimit. But it may induce some hard-to-debug flakiness if another process starts, or the current application is killed, while the rlimit is reduced, and the approach was discarded. As a workaround to ensure that the rlimit bump does not depend on the availability of a given helper, we restore the unconditional rlimit bump in bpftool for now. [0] https://lore.kernel.org/bpf/20220609143614.97837-1-quentin@isovalent.com/ [1] https://github.com/cilium/ebpf/blob/v0.9.0/rlimit/rlimit.go#L39 Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Cc: Yafang Shao <laoar.shao@gmail.com> Cc: Stanislav Fomichev <sdf@google.com> Link: https://lore.kernel.org/bpf/20220610112648.29695-2-quentin@isovalent.com
|
#
2e98964b |
|
23-May-2022 |
Daniel Müller <deso@posteo.net> |
bpftool: Use libbpf_bpf_map_type_str This change switches bpftool over to using the recently introduced libbpf_bpf_map_type_str function instead of maintaining its own string representation for the bpf_map_type enum. 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-7-deso@posteo.net
|
#
b700eeb4 |
|
23-May-2022 |
Daniel Müller <deso@posteo.net> |
bpftool: Use libbpf_bpf_prog_type_str This change switches bpftool over to using the recently introduced libbpf_bpf_prog_type_str function instead of maintaining its own string representation for the bpf_prog_type enum. Signed-off-by: Daniel Müller <deso@posteo.net> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Yonghong Song <yhs@fb.com> Acked-by: Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/bpf/20220523230428.3077108-4-deso@posteo.net
|
#
a777e18f |
|
08-Apr-2022 |
Yafang Shao <laoar.shao@gmail.com> |
bpftool: Use libbpf 1.0 API mode instead of RLIMIT_MEMLOCK We have switched to memcg-based memory accouting and thus the rlimit is not needed any more. LIBBPF_STRICT_AUTO_RLIMIT_MEMLOCK was introduced in libbpf for backward compatibility, so we can use it instead now. libbpf_set_strict_mode always return 0, so we don't need to check whether the return value is 0 or not. Signed-off-by: Yafang Shao <laoar.shao@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20220409125958.92629-4-laoar.shao@gmail.com
|
#
1824d8ea |
|
20-Mar-2022 |
Yafang Shao <laoar.shao@gmail.com> |
bpftool: Fix print error when show bpf map If there is no btf_id or frozen, it will not show the pids, but the pids don't depend on any one of them. Below is the result after this change: $ ./bpftool map show 2: lpm_trie flags 0x1 key 8B value 8B max_entries 1 memlock 4096B pids systemd(1) 3: lpm_trie flags 0x1 key 20B value 8B max_entries 1 memlock 4096B pids systemd(1) While before this change, the 'pids systemd(1)' can't be displayed. Fixes: 9330986c0300 ("bpf: Add bloom filter map implementation") Signed-off-by: Yafang Shao <laoar.shao@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220320060815.7716-1-laoar.shao@gmail.com
|
#
357b3cc3 |
|
09-Mar-2022 |
Chris J Arges <carges@cloudflare.com> |
bpftool: Ensure bytes_memlock json output is correct If a BPF map is created over 2^32 the memlock value as displayed in JSON format will be incorrect. Use atoll instead of atoi so that the correct number is displayed. ``` $ bpftool map create /sys/fs/bpf/test_bpfmap type hash key 4 \ value 1024 entries 4194304 name test_bpfmap $ bpftool map list 1: hash name test_bpfmap flags 0x0 key 4B value 1024B max_entries 4194304 memlock 4328521728B $ sudo bpftool map list -j | jq .[].bytes_memlock 33554432 ``` Signed-off-by: Chris J Arges <carges@cloudflare.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/b6601087-0b11-33cc-904a-1133d1500a10@cloudflare.com
|
#
f76d8507 |
|
16-Feb-2022 |
Jiri Olsa <jolsa@kernel.org> |
bpftool: Fix pretty print dump for maps without BTF loaded The commit e5043894b21f ("bpftool: Use libbpf_get_error() to check error") fails to dump map without BTF loaded in pretty mode (-p option). Fixing this by making sure get_map_kv_btf won't fail in case there's no BTF available for the map. Fixes: e5043894b21f ("bpftool: Use libbpf_get_error() to check error") Suggested-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20220216092102.125448-1-jolsa@kernel.org
|
#
edc21dc9 |
|
07-Feb-2022 |
Yinjun Zhang <yinjun.zhang@corigine.com> |
bpftool: Fix the error when lookup in no-btf maps When reworking btf__get_from_id() in commit a19f93cfafdf the error handling when calling bpf_btf_get_fd_by_id() changed. Before the rework if bpf_btf_get_fd_by_id() failed the error would not be propagated to callers of btf__get_from_id(), after the rework it is. This lead to a change in behavior in print_key_value() that now prints an error when trying to lookup keys in maps with no btf available. Fix this by following the way used in dumping maps to allow to look up keys in no-btf maps, by which it decides whether and where to get the btf info according to the btf value type. Fixes: a19f93cfafdf ("libbpf: Add internal helper to load BTF data by FD") Signed-off-by: Yinjun Zhang <yinjun.zhang@corigine.com> Signed-off-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Niklas Söderlund <niklas.soderlund@corigine.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/bpf/1644249625-22479-1-git-send-email-yinjun.zhang@corigine.com
|
#
622a5b58 |
|
07-Jan-2022 |
Mauricio Vásquez <mauricio@kinvolk.io> |
bpftool: Fix error check when calling hashmap__new() hashmap__new() encodes errors with ERR_PTR(), hence it's not valid to check the returned pointer against NULL and IS_ERR() has to be used instead. libbpf_get_error() can't be used in this case as hashmap__new() is not part of the public libbpf API and it'll continue using ERR_PTR() after libbpf 1.0. Fixes: 8f184732b60b ("bpftool: Switch to libbpf's hashmap for pinned paths of BPF objects") Fixes: 2828d0d75b73 ("bpftool: Switch to libbpf's hashmap for programs/maps in BTF listing") Fixes: d6699f8e0f83 ("bpftool: Switch to libbpf's hashmap for PIDs/names references") Signed-off-by: Mauricio Vásquez <mauricio@kinvolk.io> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Quentin Monnet <quentin@isovalent.com> Acked-by: Song Liu <songliubraving@fb.com> Link: https://lore.kernel.org/bpf/20220107152620.192327-2-mauricio@kinvolk.io
|
#
a15d408b |
|
01-Dec-2021 |
Andrii Nakryiko <andrii@kernel.org> |
bpftool: Migrate off of deprecated bpf_create_map_xattr() API Switch to bpf_map_create() API instead. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211201232824.3166325-4-andrii@kernel.org
|
#
e5043894 |
|
14-Nov-2021 |
Hengqi Chen <hengqi.chen@gmail.com> |
bpftool: Use libbpf_get_error() to check error Currently, LIBBPF_STRICT_ALL mode is enabled by default for bpftool which means on error cases, some libbpf APIs would return NULL pointers. This makes IS_ERR check failed to detect such cases and result in segfault error. Use libbpf_get_error() instead like we do in libbpf itself. Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211115012436.3143318-1-hengqi.chen@gmail.com
|
#
3811e275 |
|
10-Nov-2021 |
Quentin Monnet <quentin@isovalent.com> |
bpftool: Update the lists of names for maps and prog-attach types To support the different BPF map or attach types, bpftool must remain up-to-date with the types supported by the kernel. Let's update the lists, by adding the missing Bloom filter map type and the perf_event attach type. Both missing items were found with test_bpftool_synctypes.py. Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211110114632.24537-6-quentin@isovalent.com
|
#
d6699f8e |
|
23-Oct-2021 |
Quentin Monnet <quentin@isovalent.com> |
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
|
#
8f184732 |
|
23-Oct-2021 |
Quentin Monnet <quentin@isovalent.com> |
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
|
#
46241271 |
|
23-Oct-2021 |
Quentin Monnet <quentin@isovalent.com> |
bpftool: Do not expose and init hash maps for pinned path in main.c BPF programs, maps, and links, can all be listed with their pinned paths by bpftool, when the "-f" option is provided. To do so, bpftool builds hash maps containing all pinned paths for each kind of objects. These three hash maps are always initialised in main.c, and exposed through main.h. There appear to be no particular reason to do so: we can just as well make them static to the files that need them (prog.c, map.c, and link.c respectively), and initialise them only when we want to show objects and the "-f" switch is provided. This may prevent unnecessary memory allocations if the implementation of the hash maps was to change in the future. Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211023205154.6710-3-quentin@isovalent.com
|
#
c07ba629 |
|
30-Jul-2021 |
Quentin Monnet <quentin@isovalent.com> |
tools: bpftool: Update and synchronise option list in doc and help msg All bpftool commands support the options for JSON output and debug from libbpf. In addition, some commands support additional options corresponding to specific use cases. The list of options described in the man pages for the different commands are not always accurate. The messages for interactive help are mostly limited to HELP_SPEC_OPTIONS, and are even less representative of the actual set of options supported for the commands. Let's update the lists: - HELP_SPEC_OPTIONS is modified to contain the "default" options (JSON and debug), and to be extensible (no ending curly bracket). - All commands use HELP_SPEC_OPTIONS in their help message, and then complete the list with their specific options. - The lists of options in the man pages are updated. - The formatting of the list for bpftool.rst is adjusted to match formatting for the other man pages. This is for consistency, and also because it will be helpful in a future patch to automatically check that the files are synchronised. Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20210730215435.7095-5-quentin@isovalent.com
|
#
86f4b7f2 |
|
29-Jul-2021 |
Quentin Monnet <quentin@isovalent.com> |
tools: Replace btf__get_from_id() with btf__load_from_kernel_by_id() Replace the calls to function btf__get_from_id(), which we plan to deprecate before the library reaches v1.0, with calls to btf__load_from_kernel_by_id() in tools/ (bpftool, perf, selftests). Update the surrounding code accordingly (instead of passing a pointer to the btf struct, get it as a return value from the function). Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20210729162028.29512-6-quentin@isovalent.com
|
#
4bbb3583 |
|
13-Mar-2021 |
Andrii Nakryiko <andrii@kernel.org> |
bpftool: Fix maybe-uninitialized warnings Somehow when bpftool is compiled in -Og mode, compiler produces new warnings about possibly uninitialized variables. Fix all the reported problems. Fixes: 2119f2189df1 ("bpftool: add C output format option to btf dump subcommand") Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20210313210920.1959628-3-andrii@kernel.org
|
#
864ab061 |
|
06-Nov-2020 |
KP Singh <kpsingh@google.com> |
bpftool: Add support for task local storage Updates the binary to handle the BPF_MAP_TYPE_TASK_STORAGE as "task_storage" for printing and parsing. Also updates the documentation and bash completion Signed-off-by: KP Singh <kpsingh@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Song Liu <songliubraving@fb.com> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/20201106103747.2780972-5-kpsingh@chromium.org
|
#
e3b9626f |
|
10-Sep-2020 |
Quentin Monnet <quentin@isovalent.com> |
tools: bpftool: Add "inner_map" to "bpftool map create" outer maps There is no support for creating maps of types array-of-map or hash-of-map in bpftool. This is because the kernel needs an inner_map_fd to collect metadata on the inner maps to be supported by the new map, but bpftool does not provide a way to pass this file descriptor. Add a new optional "inner_map" keyword that can be used to pass a reference to a map, retrieve a fd to that map, and pass it as the inner_map_fd. Add related documentation and bash completion. Note that we can reference the inner map by its name, meaning we can have several times the keyword "name" with different meanings (mandatory outer map name, and possibly a name to use to find the inner_map_fd). The bash completion will offer it just once, and will not suggest "name" on the following command: # bpftool map create /sys/fs/bpf/my_outer_map type hash_of_maps \ inner_map name my_inner_map [TAB] Fixing that specific case seems too convoluted. Completion will work as expected, however, if the outer map name comes first and the "inner_map name ..." is passed second. Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20200910102652.10509-4-quentin@isovalent.com
|
#
86233ce3 |
|
10-Sep-2020 |
Quentin Monnet <quentin@isovalent.com> |
tools: bpftool: Keep errors for map-of-map dumps if distinct from ENOENT When dumping outer maps or prog_array maps, and on lookup failure, bpftool simply skips the entry with no error message. This is because the kernel returns non-zero when no value is found for the provided key, which frequently happen for those maps if they have not been filled. When such a case occurs, errno is set to ENOENT. It seems unlikely we could receive other error codes at this stage (we successfully retrieved map info just before), but to be on the safe side, let's skip the entry only if errno was ENOENT, and not for the other errors. v3: New patch Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20200910102652.10509-3-quentin@isovalent.com
|
#
a20693b6 |
|
10-Sep-2020 |
Quentin Monnet <quentin@isovalent.com> |
tools: bpftool: Clean up function to dump map entry The function used to dump a map entry in bpftool is a bit difficult to follow, as a consequence to earlier refactorings. There is a variable ("num_elems") which does not appear to be necessary, and the error handling would look cleaner if moved to its own function. Let's clean it up. No functional change. v2: - v1 was erroneously removing the check on fd maps in an attempt to get support for outer map dumps. This is already working. Instead, v2 focuses on cleaning up the dump_map_elem() function, to avoid similar confusion in the future. Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20200910102652.10509-2-quentin@isovalent.com
|
#
8ea63684 |
|
25-Aug-2020 |
KP Singh <kpsingh@google.com> |
bpf: Implement bpf_local_storage for inodes Similar to bpf_local_storage for sockets, add local storage for inodes. The life-cycle of storage is managed with the life-cycle of the inode. i.e. the storage is destroyed along with the owning inode. The BPF LSM allocates an __rcu pointer to the bpf_local_storage in the security blob which are now stackable and can co-exist with other LSMs. Signed-off-by: KP Singh <kpsingh@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20200825182919.1118197-6-kpsingh@chromium.org
|
#
9023497d |
|
24-Jun-2020 |
Tobias Klauser <tklauser@distanz.ch> |
tools, bpftool: Define prog_type_name array only once Define prog_type_name in prog.c instead of main.h so it is only defined once. This leads to a slight decrease in the binary size of bpftool. Before: text data bss dec hex filename 401032 11936 1573160 1986128 1e4e50 bpftool After: text data bss dec hex filename 399024 11168 1573160 1983352 1e4378 bpftool Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/bpf/20200624143124.12914-1-tklauser@distanz.ch
|
#
d53dee3f |
|
19-Jun-2020 |
Andrii Nakryiko <andriin@fb.com> |
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
|
#
a479b8ce |
|
19-Jun-2020 |
Andrii Nakryiko <andriin@fb.com> |
tools/bpftool: Move map/prog parsing logic into common Move functions that parse map and prog by id/tag/name/etc outside of map.c/prog.c, respectively. These functions are used outside of those files and are generic enough to be in common. This also makes heavy-weight map.c and prog.c more decoupled from the rest of bpftool files and facilitates more lightweight bootstrap bpftool variant. 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-5-andriin@fb.com
|
#
1c7fb20d |
|
16-Jun-2020 |
Tobias Klauser <tklauser@distanz.ch> |
tools, bpftool: Add ringbuf map type to map command docs Commit c34a06c56df7 ("tools/bpftool: Add ringbuf map to a list of known map types") added the symbolic "ringbuf" name. Document it in the bpftool map command docs and usage as well. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Andrii Nakryiko <andriin@fb.com> Acked-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20200616113303.8123-1-tklauser@distanz.ch
|
#
c34a06c5 |
|
15-Jun-2020 |
Andrii Nakryiko <andriin@fb.com> |
tools/bpftool: Add ringbuf map to a list of known map types Add symbolic name "ringbuf" to map to BPF_MAP_TYPE_RINGBUF. Without this, users will see "type 27" instead of "ringbuf" in `map show` output. Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20200615225355.366256-1-andriin@fb.com
|
#
90040351 |
|
22-May-2020 |
Quentin Monnet <quentin@isovalent.com> |
tools, bpftool: Clean subcommand help messages This is a clean-up for the formatting of the do_help functions for bpftool's subcommands. The following fixes are included: - Do not use argv[-2] for "iter" help message, as the help is shown by default if no "iter" action is selected, resulting in messages looking like "./bpftool bpftool pin...". - Do not print unused HELP_SPEC_PROGRAM in help message for "bpftool link". - Andrii used argument indexing to avoid having multiple occurrences of bin_name and argv[-2] in the fprintf() for the help message, for "bpftool gen" and "bpftool link". Let's reuse this for all other help functions. We can remove up to thirty arguments for the "bpftool map" help message. - Harmonise all functions, e.g. use ending quotes-comma on a separate line. Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20200523010751.23465-1-quentin@isovalent.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
c8caa0bb |
|
11-May-2020 |
Quentin Monnet <quentin@isovalent.com> |
tools, bpftool: Minor fixes for documentation Bring minor improvements to bpftool documentation. Fix or harmonise formatting, update map types (including in interactive help), improve description for "map create", fix a build warning due to a missing line after the double-colon for the "bpftool prog profile" example, complete/harmonise/sort the list of related bpftool man pages in footers. v2: - Remove (instead of changing) mark-up on "value" in bpftool-map.rst, when it does not refer to something passed on the command line. - Fix an additional typo ("hexadeximal") in the same file. Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20200511161536.29853-3-quentin@isovalent.com
|
#
75a1e792 |
|
12-Mar-2020 |
Quentin Monnet <quentin@isovalent.com> |
tools: bpftool: Allow all prog/map handles for pinning objects Documentation and interactive help for bpftool have always explained that the regular handles for programs (id|name|tag|pinned) and maps (id|name|pinned) can be passed to the utility when attempting to pin objects (bpftool prog pin PROG / bpftool map pin MAP). THIS IS A LIE!! The tool actually accepts only ids, as the parsing is done in do_pin_any() in common.c instead of reusing the parsing functions that have long been generic for program and map handles. Instead of fixing the doc, fix the code. It is trivial to reuse the generic parsing, and to simplify do_pin_any() in the process. Do not accept to pin multiple objects at the same time with prog_parse_fds() or map_parse_fds() (this would require a more complex syntax for passing multiple sysfs paths and validating that they correspond to the number of e.g. programs we find for a given name or tag). Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/20200312184608.12050-2-quentin@isovalent.com
|
#
229c3b47 |
|
20-Jan-2020 |
Toke Høiland-Jørgensen <toke@redhat.com> |
bpftool: Use consistent include paths for libbpf Fix bpftool to include libbpf header files with the bpf/ prefix, to be consistent with external users of the library. Also ensure that all includes of exported libbpf header files (those that are exported on 'make install' of the library) use bracketed includes instead of quoted. To make sure no new files are introduced that doesn't include the bpf/ prefix in its include, remove tools/lib/bpf from the include path entirely, and use tools/lib instead. Fixes: 6910d7d3867a ("selftests/bpf: Ensure bpf_helper_defs.h are taken from selftests dir") Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/157952560684.1683545.4765181397974997027.stgit@toke.dk
|
#
4e1ea332 |
|
15-Jan-2020 |
Martin KaFai Lau <kafai@fb.com> |
bpftool: Support dumping a map with btf_vmlinux_value_type_id This patch makes bpftool support dumping a map's value properly when the map's value type is a type of the running kernel's btf. (i.e. map_info.btf_vmlinux_value_type_id is set instead of map_info.btf_value_type_id). The first usecase is for the BPF_MAP_TYPE_STRUCT_OPS. Signed-off-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20200115230044.1103008-1-kafai@fb.com
|
#
84c72cee |
|
15-Jan-2020 |
Martin KaFai Lau <kafai@fb.com> |
bpftool: Add struct_ops map name This patch adds BPF_MAP_TYPE_STRUCT_OPS to "struct_ops" name mapping so that "bpftool map show" can print the "struct_ops" map type properly. [root@arch-fb-vm1 bpf]# ~/devshare/fb-kernel/linux/tools/bpf/bpftool/bpftool map show id 8 8: struct_ops name dctcp flags 0x0 key 4B value 256B max_entries 1 memlock 4096B btf_id 7 Signed-off-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20200115230037.1102674-1-kafai@fb.com
|
#
188a4866 |
|
15-Jan-2020 |
Martin KaFai Lau <kafai@fb.com> |
bpftool: Fix missing BTF output for json during map dump The btf availability check is only done for plain text output. It causes the whole BTF output went missing when json_output is used. This patch simplifies the logic a little by avoiding passing "int btf" to map_dump(). For plain text output, the btf_wtr is only created when the map has BTF (i.e. info->btf_id != 0). The nullness of "json_writer_t *wtr" in map_dump() alone can decide if dumping BTF output is needed. As long as wtr is not NULL, map_dump() will print out the BTF-described data whenever a map has BTF available (i.e. info->btf_id != 0) regardless of json or plain-text output. In do_dump(), the "int btf" is also renamed to "int do_plain_btf". Fixes: 99f9863a0c45 ("bpftool: Match maps by name") Signed-off-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Cc: Paul Chaignon <paul.chaignon@orange.com> Link: https://lore.kernel.org/bpf/20200115230025.1101828-1-kafai@fb.com
|
#
d7de7267 |
|
15-Jan-2020 |
Martin KaFai Lau <kafai@fb.com> |
bpftool: Fix a leak of btf object When testing a map has btf or not, maps_have_btf() tests it by actually getting a btf_fd from sys_bpf(BPF_BTF_GET_FD_BY_ID). However, it forgot to btf__free() it. In maps_have_btf() stage, there is no need to test it by really calling sys_bpf(BPF_BTF_GET_FD_BY_ID). Testing non zero info.btf_id is good enough. Also, the err_close case is unnecessary, and also causes double close() because the calling func do_dump() will close() all fds again. Fixes: 99f9863a0c45 ("bpftool: Match maps by name") Signed-off-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Cc: Paul Chaignon <paul.chaignon@orange.com> Link: https://lore.kernel.org/bpf/20200115230019.1101352-1-kafai@fb.com
|
#
99f9863a |
|
13-Dec-2019 |
Paul Chaignon <paul.chaignon@orange.com> |
bpftool: Match maps by name This patch implements lookup by name for maps and changes the behavior of lookups by tag to be consistent with prog subcommands. Similarly to program subcommands, the show and dump commands will return all maps with the given name (or tag), whereas other commands will error out if several maps have the same name (resp. tag). When a map has BTF info, it is dumped in JSON with available BTF info. This patch requires that all matched maps have BTF info before switching the output format to JSON. Signed-off-by: Paul Chaignon <paul.chaignon@orange.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/8de1c9f273860b3ea1680502928f4da2336b853e.1576263640.git.paul.chaignon@gmail.com
|
#
0bb52b0d |
|
21-Aug-2019 |
Quentin Monnet <quentin@isovalent.com> |
tools: bpftool: add "bpftool map freeze" subcommand Add a new subcommand to freeze maps from user space. Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
c354ff2e |
|
21-Aug-2019 |
Quentin Monnet <quentin@isovalent.com> |
tools: bpftool: show frozen status for maps When listing maps, read their "frozen" status from procfs, and tell if maps are frozen. As commit log for map freezing command mentions that the feature might be extended with flags (e.g. for write-only instead of read-only) in the future, use an integer and not a boolean for JSON output. Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
1375dc4a |
|
26-Jul-2019 |
Toke Høiland-Jørgensen <toke@redhat.com> |
tools: Add definitions for devmap_hash map type This adds selftest and bpftool updates for the devmap_hash map type. Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Acked-by: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
1884c066 |
|
05-Jun-2019 |
Krzesimir Nowak <krzesimir@kinvolk.io> |
tools: bpftool: Fix JSON output when lookup fails In commit 9a5ab8bf1d6d ("tools: bpftool: turn err() and info() macros into functions") one case of error reporting was special cased, so it could report a lookup error for a specific key when dumping the map element. What the code forgot to do is to wrap the key and value keys into a JSON object, so an example output of pretty JSON dump of a sockhash map (which does not support looking up its values) is: [ "key": ["0x0a","0x41","0x00","0x02","0x1f","0x78","0x00","0x00" ], "value": { "error": "Operation not supported" }, "key": ["0x0a","0x41","0x00","0x02","0x1f","0x78","0x00","0x01" ], "value": { "error": "Operation not supported" } ] Note the key-value pairs inside the toplevel array. They should be wrapped inside a JSON object, otherwise it is an invalid JSON. This commit fixes this, so the output now is: [{ "key": ["0x0a","0x41","0x00","0x02","0x1f","0x78","0x00","0x00" ], "value": { "error": "Operation not supported" } },{ "key": ["0x0a","0x41","0x00","0x02","0x1f","0x78","0x00","0x01" ], "value": { "error": "Operation not supported" } } ] Fixes: 9a5ab8bf1d6d ("tools: bpftool: turn err() and info() macros into functions") Cc: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: Krzesimir Nowak <krzesimir@kinvolk.io> Acked-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
a19f89f3 |
|
26-Apr-2019 |
Martin KaFai Lau <kafai@fb.com> |
bpf: Support BPF_MAP_TYPE_SK_STORAGE in bpf map probing This patch supports probing for the new BPF_MAP_TYPE_SK_STORAGE. BPF_MAP_TYPE_SK_STORAGE enforces BTF usage, so the new probe requires to create and load a BTF also. Signed-off-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
77d76426 |
|
11-Apr-2019 |
Benjamin Poirier <bpoirier@suse.com> |
bpftool: Fix errno variable usage The test meant to use the saved value of errno. Given the current code, it makes no practical difference however. Fixes: bf598a8f0f77 ("bpftool: Improve handling of ENOENT on map dumps") Signed-off-by: Benjamin Poirier <bpoirier@suse.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Acked-by: Song Liu <songliubraving@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
8694d8c1 |
|
12-Apr-2019 |
Alban Crequy <alban@kinvolk.io> |
tools: bpftool: fix infinite loop in map create "bpftool map create" has an infinite loop on "while (argc)". The error case is missing. Symptoms: when forgetting to type the keyword 'type' in front of 'hash': $ sudo bpftool map create /sys/fs/bpf/dir/foobar hash key 8 value 8 entries 128 (infinite loop, taking all the CPU) ^C After the patch: $ sudo bpftool map create /sys/fs/bpf/dir/foobar hash key 8 value 8 entries 128 Error: unknown arg hash Fixes: 0b592b5a01be ("tools: bpftool: add map create command") Signed-off-by: Alban Crequy <alban@kinvolk.io> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Acked-by: Song Liu <songliubraving@fb.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
d1b7725d |
|
16-Apr-2019 |
Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> |
tools/bpftool: show btf_id in map listing Let's print btf id of map similar to the way we are printing it for programs. Sample output: user@test# bpftool map -f 61: lpm_trie flags 0x1 key 20B value 8B max_entries 1 memlock 4096B 133: array name test_btf_id flags 0x0 key 4B value 4B max_entries 4 memlock 4096B pinned /sys/fs/bpf/test100 btf_id 174 170: array name test_btf_id flags 0x0 key 4B value 4B max_entries 4 memlock 4096B btf_id 240 Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Song Liu <songliubraving@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
d459b59e |
|
16-Apr-2019 |
Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> |
tools/bpftool: re-organize newline printing for map listing Let's move the final newline printing in show_map_close_plain() at the end of the function because it looks correct and consistent with prog.c. Also let's do related changes for the line which prints pinned file name. Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Song Liu <songliubraving@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
3da6e7e4 |
|
15-Apr-2019 |
Benjamin Poirier <bpoirier@suse.com> |
bpftool: Improve handling of ENOSPC on reuseport_array map dumps avoids outputting a series of value: No space left on device The value itself is not wrong but bpf_fd_reuseport_array_lookup_elem() can only return it if the map was created with value_size = 8. There's nothing bpftool can do about it. Instead of repeating this error for every key in the map, print an explanatory warning and a specialized error. example before: key: 00 00 00 00 value: No space left on device key: 01 00 00 00 value: No space left on device key: 02 00 00 00 value: No space left on device Found 0 elements example after: Warning: cannot read values from reuseport_sockarray map with value_size != 8 key: 00 00 00 00 value: <cannot read> key: 01 00 00 00 value: <cannot read> key: 02 00 00 00 value: <cannot read> Found 0 elements Signed-off-by: Benjamin Poirier <bpoirier@suse.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
0478c3bf |
|
15-Apr-2019 |
Benjamin Poirier <bpoirier@suse.com> |
bpftool: Use print_entry_error() in case of ENOENT when dumping Commit bf598a8f0f77 ("bpftool: Improve handling of ENOENT on map dumps") used print_entry_plain() in case of ENOENT. However, that commit introduces dead code. Per-cpu maps are zero-filled. When reading them, it's all or nothing. There will never be a case where some cpus have an entry and others don't. The truth is that ENOENT is an error case. Use print_entry_error() to output the desired message. That function's "value" parameter is also renamed to indicate that we never use it for an actual map value. The output format is unchanged. Signed-off-by: Benjamin Poirier <bpoirier@suse.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
817998af |
|
09-Apr-2019 |
Daniel Borkmann <daniel@iogearbox.net> |
bpf: bpftool support for dumping data/bss/rodata sections Add the ability to bpftool to handle BTF Var and DataSec kinds in order to dump them out of btf_dumper_type(). The value has a single object with the section name, which itself holds an array of variables it dumps. A single variable is an object by itself printed along with its name. From there further type information is dumped along with corresponding value information. Example output from .rodata: # ./bpftool m d i 150 [{ "value": { ".rodata": [{ "load_static_data.bar": 18446744073709551615 },{ "num2": 24 },{ "num5": 43947 },{ "num6": 171 },{ "str0": [97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,0,0,0,0,0,0 ] },{ "struct0": { "a": 42, "b": 4278120431, "c": 1229782938247303441 } },{ "struct2": { "a": 0, "b": 0, "c": 0 } } ] } } ] Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
d76198b0 |
|
28-Jan-2019 |
Jakub Kicinski <kuba@kernel.org> |
tools: bpftool: warn about risky prog array updates When prog array is updated with bpftool users often refer to the map via the ID. Unfortunately, that's likely to lead to confusion because prog arrays get flushed when the last user reference is gone. If there is no other reference bpftool will create one, update successfully just to close the map again and have it flushed. Warn about this case in non-JSON mode. If the problem continues causing confusion we can remove the support for referring to a map by ID for prog array update completely. For now it seems like the potential inconvenience to users who know what they're doing outweighs the benefit. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Acked-by: Song Liu <songliubraving@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
8c79b356 |
|
28-Jan-2019 |
Jakub Kicinski <kuba@kernel.org> |
tools: bpftool: fix crash with un-owned prog arrays Prog arrays don't have 'owner_prog_type' and 'owner_jited' fields in their fdinfo when they are created. Those fields are set and reported when first program is checked for compatibility by bpf_prog_array_compatible(). This means that bpftool cannot expect the fields to always be there. Currently trying to show maps on a system with an un-owned prog array leads to a crash: $ bpftool map show 389: prog_array name tail_call_map flags 0x0 Error: key 'owner_prog_type' not found in fdinfo Error: key 'owner_jited' not found in fdinfo key 4B value 4B max_entries 4 memlock 4096B Segmentation fault (core dumped) We pass a NULL pointer to atoi(). Remove the assumption that fdinfo keys are always present. Add missing validations and remove the p_err() calls which may lead to broken JSON output as caller will not propagate the failure. Fixes: 99a44bef5870 ("tools: bpftool: add owner_prog_type and owner_jited to bpftool output") Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Acked-by: Song Liu <songliubraving@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
b0ca5ecb |
|
20-Jan-2019 |
Paolo Abeni <pabeni@redhat.com> |
bpftool: fix percpu maps updating When updating a percpu map, bpftool currently copies the provided value only into the first per CPU copy of the specified value, all others instances are left zeroed. This change explicitly copies the user-provided bytes to all the per CPU instances, keeping the sub-command syntax unchanged. v2 -> v3: - drop unused argument, as per Quentin's suggestion v1 -> v2: - rename the helper as per Quentin's suggestion Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
f99e1663 |
|
17-Jan-2019 |
Quentin Monnet <quentin@isovalent.com> |
tools: bpftool: add probes for eBPF map types Add new probes for eBPF map types, to detect what are the ones available on the system. Try creating one map of each type, and see if the kernel complains. Sample output: # bpftool feature probe kernel ... Scanning eBPF map types... eBPF map_type hash is available eBPF map_type array is available eBPF map_type prog_array is available ... # bpftool --json --pretty feature probe kernel { ... "map_types": { "have_hash_map_type": true, "have_array_map_type": true, "have_prog_array_map_type": true, ... } } v5: - In libbpf.map, move global symbol to the new LIBBPF_0.0.2 section. v3: - Use a switch with all enum values for setting specific map parameters, so that gcc complains at compile time (-Wswitch-enum) if new map types were added to the kernel but libbpf was not updated. v2: - Move probes from bpftool to libbpf. - Remove C-style macros output from this patch. Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
74f312ef |
|
16-Jan-2019 |
Stanislav Fomichev <sdf@google.com> |
bpftool: add pop and dequeue commands This is intended to be used with queues and stacks, it pops and prints the last element via bpf_map_lookup_and_delete_elem. Example: bpftool map create /sys/fs/bpf/q type queue value 4 entries 10 name q bpftool map push pinned /sys/fs/bpf/q value 0 1 2 3 bpftool map pop pinned /sys/fs/bpf/q value: 00 01 02 03 bpftool map pop pinned /sys/fs/bpf/q Error: empty map bpftool map create /sys/fs/bpf/s type stack value 4 entries 10 name s bpftool map enqueue pinned /sys/fs/bpf/s value 0 1 2 3 bpftool map dequeue pinned /sys/fs/bpf/s value: 00 01 02 03 bpftool map dequeue pinned /sys/fs/bpf/s Error: empty map Signed-off-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
549d4d3d |
|
16-Jan-2019 |
Stanislav Fomichev <sdf@google.com> |
bpftool: add push and enqueue commands This is intended to be used with queues and stacks and be more user-friendly than 'update' without the key. Example: bpftool map create /sys/fs/bpf/q type queue value 4 entries 10 name q bpftool map push pinned /sys/fs/bpf/q value 0 1 2 3 bpftool map peek pinned /sys/fs/bpf/q value: 00 01 02 03 bpftool map create /sys/fs/bpf/s type stack value 4 entries 10 name s bpftool map enqueue pinned /sys/fs/bpf/s value 0 1 2 3 bpftool map peek pinned /sys/fs/bpf/s value: 00 01 02 03 Signed-off-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
66cf6e0b |
|
16-Jan-2019 |
Stanislav Fomichev <sdf@google.com> |
bpftool: add peek command This is intended to be used with queues and stacks and be more user-friendly than 'lookup' without key/value. Example: bpftool map create /sys/fs/bpf/q type queue value 4 entries 10 name q bpftool map update pinned /sys/fs/bpf/q value 0 1 2 3 bpftool map peek pinned /sys/fs/bpf/q value: 00 01 02 03 Signed-off-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
04a5d323 |
|
16-Jan-2019 |
Stanislav Fomichev <sdf@google.com> |
bpftool: don't print empty key/value for maps When doing dump or lookup, don't print key if key_size == 0 or value if value_size == 0. The initial usecase is queue and stack, where we have only values. This is for regular output only, json still has all the fields. Before: bpftool map create /sys/fs/bpf/q type queue value 4 entries 10 name q bpftool map update pinned /sys/fs/bpf/q value 0 1 2 3 bpftool map lookup pinned /sys/fs/bpf/q key: value: 00 01 02 03 After: bpftool map create /sys/fs/bpf/q type queue value 4 entries 10 name q bpftool map update pinned /sys/fs/bpf/q value 0 1 2 3 bpftool map lookup pinned /sys/fs/bpf/q value: 00 01 02 03 Signed-off-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
8a89fff6 |
|
16-Jan-2019 |
Stanislav Fomichev <sdf@google.com> |
bpftool: make key optional in lookup command Bpftool expects key for 'lookup' operations. For some map types, key should not be specified. Support looking up those map types. Before: bpftool map create /sys/fs/bpf/q type queue value 4 entries 10 name q bpftool map update pinned /sys/fs/bpf/q value 0 1 2 3 bpftool map lookup pinned /sys/fs/bpf/q Error: did not find key After: bpftool map create /sys/fs/bpf/q type queue value 4 entries 10 name q bpftool map update pinned /sys/fs/bpf/q value 0 1 2 3 bpftool map lookup pinned /sys/fs/bpf/q key: value: 00 01 02 03 Signed-off-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
7d7209cb |
|
16-Jan-2019 |
Stanislav Fomichev <sdf@google.com> |
bpftool: make key and value optional in update command Bpftool expects both key and value for 'update' operations. For some map types, key should not be specified. Support updating those map types. Before: bpftool map create /sys/fs/bpf/q type queue value 4 entries 10 name q bpftool map update pinned /sys/fs/bpf/q value 0 1 2 3 Error: did not find key After: bpftool map create /sys/fs/bpf/q type queue value 4 entries 10 name q bpftool map update pinned /sys/fs/bpf/q value 0 1 2 3 Signed-off-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
02ff58dc |
|
12-Dec-2018 |
Jakub Kicinski <kuba@kernel.org> |
tools: bpftool: replace Netronome boilerplate with SPDX license headers Replace the repeated license text with SDPX identifiers. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Roman Gushchin <guro@fb.com> Acked-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Yonghong Song <yhs@fb.com> Acked-by: Stanislav Fomichev <sdf@google.com> Acked-by: Sean Young <sean@mess.org> Acked-by: Jiri Benc <jbenc@redhat.com> Acked-by: David Calavera <david.calavera@gmail.com> Acked-by: Andrey Ignatov <rdna@fb.com> Acked-by: Joe Stringer <joe@wand.net.nz> Acked-by: David Ahern <dsahern@gmail.com> Acked-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> Acked-by: Petar Penkov <ppenkov@stanford.edu> Acked-by: Sandipan Das <sandipan@linux.ibm.com> Acked-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> Acked-by: Stephen Hemminger <stephen@networkplumber.org> Acked-by: John Fastabend <john.fastabend@gmail.com> Acked-by: Taeung Song <treeze.taeung@gmail.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Acked-by: Daniel Borkmann <daniel@iogearbox.net> CC: okash.khawaja@gmail.com Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
99a44bef |
|
30-Nov-2018 |
Quentin Monnet <quentin@isovalent.com> |
tools: bpftool: add owner_prog_type and owner_jited to bpftool output For prog array maps, the type of the owner program, and the JIT-ed state of that program, are available from the file descriptor information under /proc. Add them to "bpftool map show" output. Example output: # bpftool map show 158225: prog_array name jmp_table flags 0x0 key 4B value 4B max_entries 8 memlock 4096B owner_prog_type flow_dissector owner jited # bpftool --json --pretty map show [{ "id": 1337, "type": "prog_array", "name": "jmp_table", "flags": 0, "bytes_key": 4, "bytes_value": 4, "max_entries": 8, "bytes_memlock": 4096, "owner_prog_type": "flow_dissector", "owner_jited": true } ] As we move the table used for associating names to program types, complete it with the missing types (lwt_seg6local and sk_reuseport). Also add missing types to the help message for "bpftool prog" (sk_reuseport and flow_dissector). Suggested-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
1d2f44ca |
|
23-Nov-2018 |
Martin KaFai Lau <kafai@fb.com> |
libbpf: Name changing for btf_get_from_id s/btf_get_from_id/btf__get_from_id/ to restore the API naming convention. Signed-off-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Andrey Ignatov <rdna@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
ffac28f9 |
|
23-Nov-2018 |
David Calavera <david.calavera@gmail.com> |
bpf: align map type names formatting. Make the formatting for map_type_name array consistent. Signed-off-by: David Calavera <david.calavera@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
197c2dac |
|
22-Nov-2018 |
David Calavera <david.calavera@gmail.com> |
bpf: Add BPF_MAP_TYPE_QUEUE and BPF_MAP_TYPE_STACK to bpftool-map I noticed that these two new BPF Maps are not defined in bpftool. This patch defines those two maps and adds their names to the bpftool-map documentation. Signed-off-by: David Calavera <david.calavera@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
d7f5b5e0 |
|
19-Nov-2018 |
Yonghong Song <yhs@fb.com> |
tools/bpf: refactor to implement btf_get_from_id() in lib/bpf The function get_btf() is implemented in tools/bpf/bpftool/map.c to get a btf structure given a map_info. This patch refactored this function to be function btf_get_from_id() in tools/lib/bpf so that it can be used later. Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
bf598a8f |
|
08-Nov-2018 |
David Ahern <dsahern@gmail.com> |
bpftool: Improve handling of ENOENT on map dumps bpftool output is not user friendly when dumping a map with only a few populated entries: $ bpftool map 1: devmap name tx_devmap flags 0x0 key 4B value 4B max_entries 64 memlock 4096B 2: array name tx_idxmap flags 0x0 key 4B value 4B max_entries 64 memlock 4096B $ bpftool map dump id 1 key: 00 00 00 00 value: No such file or directory key: 01 00 00 00 value: No such file or directory key: 02 00 00 00 value: No such file or directory key: 03 00 00 00 value: 03 00 00 00 Handle ENOENT by keeping the line format sane and dumping "<no entry>" for the value $ bpftool map dump id 1 key: 00 00 00 00 value: <no entry> key: 01 00 00 00 value: <no entry> key: 02 00 00 00 value: <no entry> key: 03 00 00 00 value: 03 00 00 00 ... Signed-off-by: David Ahern <dsahern@gmail.com> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
8302b9bd |
|
06-Nov-2018 |
Quentin Monnet <quentin@isovalent.com> |
tools: bpftool: adjust rlimit RLIMIT_MEMLOCK when loading programs, maps The limit for memory locked in the kernel by a process is usually set to 64 kbytes by default. This can be an issue when creating large BPF maps and/or loading many programs. A workaround is to raise this limit for the current process before trying to create a new BPF map. Changing the hard limit requires the CAP_SYS_RESOURCE and can usually only be done by root user (for non-root users, a call to setrlimit fails (and sets errno) and the program simply goes on with its rlimit unchanged). There is no API to get the current amount of memory locked for a user, therefore we cannot raise the limit only when required. One solution, used by bcc, is to try to create the map, and on getting a EPERM error, raising the limit to infinity before giving another try. Another approach, used in iproute2, is to raise the limit in all cases, before trying to create the map. Here we do the same as in iproute2: the rlimit is raised to infinity before trying to load programs or to create maps with bpftool. Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
0b592b5a |
|
15-Oct-2018 |
Jakub Kicinski <kuba@kernel.org> |
tools: bpftool: add map create command Add a way of creating maps from user space. The command takes as parameters most of the attributes of the map creation system call command. After map is created its pinned to bpffs. This makes it possible to easily and dynamically (without rebuilding programs) test various corner cases related to map creation. Map type names are taken from bpftool's array used for printing. In general these days we try to make use of libbpf type names, but there are no map type names in libbpf as of today. As with most features I add the motivation is testing (offloads) :) Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
8ec92dc2 |
|
08-Oct-2018 |
Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> |
tools/bpf: bpftool, print strerror when map lookup error occurs Since map lookup error can be ENOENT or EOPNOTSUPP, let's print strerror() as error message in normal and JSON output. This patch adds helper function print_entry_error() to print entry from lookup error occurs Example: Following example dumps a map which does not support lookup. Output before: root# bpftool map -jp dump id 40 [ "key": ["0x0a","0x00","0x00","0x00" ], "value": { "error": "can\'t lookup element" }, "key": ["0x0b","0x00","0x00","0x00" ], "value": { "error": "can\'t lookup element" } ] root# bpftool map dump id 40 can't lookup element with key: 0a 00 00 00 can't lookup element with key: 0b 00 00 00 Found 0 elements Output after changes: root# bpftool map dump -jp id 45 [ "key": ["0x0a","0x00","0x00","0x00" ], "value": { "error": "Operation not supported" }, "key": ["0x0b","0x00","0x00","0x00" ], "value": { "error": "Operation not supported" } ] root# bpftool map dump id 45 key: 0a 00 00 00 value: Operation not supported key: 0b 00 00 00 value: Operation not supported Found 0 elements Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Song Liu <songliubraving@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
18a781da |
|
08-Oct-2018 |
Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> |
tools/bpf: bpftool, split the function do_dump() do_dump() function in bpftool/map.c has deep indentations. In order to reduce deep indent, let's move element printing code out of do_dump() into dump_map_elem() function. Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Song Liu <songliubraving@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
e5487092 |
|
28-Sep-2018 |
Roman Gushchin <guro@fb.com> |
bpftool: add support for PERCPU_CGROUP_STORAGE maps This commit adds support for BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE map type. Signed-off-by: Roman Gushchin <guro@fb.com> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Song Liu <songliubraving@fb.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
7ea3c406 |
|
21-Sep-2018 |
Roman Gushchin <guro@fb.com> |
bpftool: add support for BPF_MAP_TYPE_REUSEPORT_SOCKARRAY maps Add BPF_MAP_TYPE_REUSEPORT_SOCKARRAY map type to the list of maps types which bpftool recognizes. Signed-off-by: Roman Gushchin <guro@fb.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Jakub Kicinski <jakub.kicinski@netronome.com> Cc: Yonghong Song <yhs@fb.com> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Song Liu <songliubraving@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
ad3338d2 |
|
06-Sep-2018 |
Yonghong Song <yhs@fb.com> |
tools/bpf: bpftool: support prog array map and map of maps Currently, prog array map and map of maps are not supported in bpftool. This patch added the support. Different from other map types, for prog array map and map of maps, the key returned bpf_get_next_key() may not point to a valid value. So for these two map types, no error will be printed out when such a scenario happens. The following is the plain and json dump if btf is not available: $ ./bpftool map dump id 10 key: 08 00 00 00 value: 5c 01 00 00 Found 1 element $ ./bpftool -jp map dump id 10 [{ "key": ["0x08","0x00","0x00","0x00" ], "value": ["0x5c","0x01","0x00","0x00" ] }] If the BTF is available, the dump looks below: $ ./bpftool map dump id 2 [{ "key": 0, "value": 7 } ] $ ./bpftool -jp map dump id 2 [{ "key": ["0x00","0x00","0x00","0x00" ], "value": ["0x07","0x00","0x00","0x00" ], "formatted": { "key": 0, "value": 7 } }] Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
97911e0c |
|
31-Aug-2018 |
Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> |
tools/bpf: bpftool, add xskmap in map types When listed all maps, bpftool currently shows (null) for xskmap. Added xskmap type in map_type_name[] to show correct type. Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
1a86ad89 |
|
29-Aug-2018 |
Yonghong Song <yhs@fb.com> |
tools/bpf: bpftool: add btf percpu map formated dump The btf pretty print is added to percpu arraymap, percpu hashmap and percpu lru hashmap. For each <key, value> pair, the following will be added to plain/json output: { "key": <pretty_print_key>, "values": [{ "cpu": 0, "value": <pretty_print_value_on_cpu0> },{ "cpu": 1, "value": <pretty_print_value_on_cpu1> },{ .... },{ "cpu": n, "value": <pretty_print_value_on_cpun> } ] } For example, the following could be part of plain or json formatted output: { "key": 0, "values": [{ "cpu": 0, "value": { "ui32": 0, "ui16": 0, } },{ "cpu": 1, "value": { "ui32": 1, "ui16": 0, } },{ "cpu": 2, "value": { "ui32": 2, "ui16": 0, } },{ "cpu": 3, "value": { "ui32": 3, "ui16": 0, } } ] } Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
34a6bbb8 |
|
02-Aug-2018 |
Roman Gushchin <guro@fb.com> |
bpftool: add support for CGROUP_STORAGE maps Add BPF_MAP_TYPE_CGROUP_STORAGE maps to the list of maps types which bpftool recognizes. Signed-off-by: Roman Gushchin <guro@fb.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
573b3aa6 |
|
30-Jul-2018 |
Yonghong Song <yhs@fb.com> |
tools/bpftool: fix a percpu_array map dump problem I hit the following problem when I tried to use bpftool to dump a percpu array. $ sudo ./bpftool map show 61: percpu_array name stub flags 0x0 key 4B value 4B max_entries 1 memlock 4096B ... $ sudo ./bpftool map dump id 61 bpftool: malloc.c:2406: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || \ ((unsigned long) (old_size) >= MINSIZE && \ prev_inuse (old_top) && \ ((unsigned long) old_end & (pagesize - 1)) == 0)' failed. Aborted Further debugging revealed that this is due to miscommunication between bpftool and kernel. For example, for the above percpu_array with value size of 4B. The map info returned to user space has value size of 4B. In bpftool, the values array for lookup is allocated like: info->value_size * get_possible_cpus() = 4 * get_possible_cpus() In kernel (kernel/bpf/syscall.c), the values array size is rounded up to multiple of 8. round_up(map->value_size, 8) * num_possible_cpus() = 8 * num_possible_cpus() So when kernel copies the values to user buffer, the kernel will overwrite beyond user buffer boundary. This patch fixed the issue by allocating and stepping through percpu map value array properly in bpftool. Fixes: 71bb428fe2c19 ("tools: bpf: add bpftool") Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
2cc512c1 |
|
23-Jul-2018 |
YueHaibing <yuehaibing@huawei.com> |
bpf: btf: fix inconsistent IS_ERR and PTR_ERR Fix inconsistent IS_ERR and PTR_ERR in get_btf, the proper pointer to be passed as argument is '*btf' This issue was detected with the help of Coccinelle. Fixes: 2d3feca8c44f ("bpf: btf: print map dump and lookup with btf info") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: David S. Miller <davem@davemloft.net> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
2d3feca8 |
|
13-Jul-2018 |
Okash Khawaja <osk@fb.com> |
bpf: btf: print map dump and lookup with btf info This patch augments the output of bpftool's map dump and map lookup commands to print data along side btf info, if the correspondin btf info is available. The outputs for each of map dump and map lookup commands are augmented in two ways: 1. when neither of -j and -p are supplied, btf-ful map data is printed whose aim is human readability. This means no commitments for json- or backward- compatibility. 2. when either -j or -p are supplied, a new json object named "formatted" is added for each key-value pair. This object contains the same data as the key-value pair, but with btf info. "formatted" object promises json- and backward- compatibility. Below is a sample output. $ bpftool map dump -p id 8 [{ "key": ["0x0f","0x00","0x00","0x00" ], "value": ["0x03", "0x00", "0x00", "0x00", ... ], "formatted": { "key": 15, "value": { "int_field": 3, ... } } } ] This patch calls btf_dumper introduced in previous patch to accomplish the above. Indeed, btf-ful info is only displayed if btf data for the given map is available. Otherwise existing output is displayed as-is. Signed-off-by: Okash Khawaja <osk@fb.com> Acked-by: Martin KaFai Lau <kafai@fb.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
3ff5a4dc |
|
10-Jul-2018 |
Jakub Kicinski <kuba@kernel.org> |
tools: bpftool: allow reuse of maps with bpftool prog load Add map parameter to prog load which will allow reuse of existing maps instead of creating new ones. We need feature detection and compat code for reallocarray, since it's not available in many libc versions. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
71e07ddc |
|
28-Jun-2018 |
Jakub Kicinski <kuba@kernel.org> |
tools: bpftool: drop unnecessary Author comments Drop my author comments, those are from the early days of bpftool and make little sense in tree, where we have quite a few people contributing and git to attribute the work. While at it bump some copyrights. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
62c52d1f |
|
14-May-2018 |
John Fastabend <john.fastabend@gmail.com> |
bpf: bpftool, support for sockhash This adds the SOCKHASH map type to bpftools so that we get correct pretty printing. Signed-off-by: John Fastabend <john.fastabend@gmail.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
f412eed9 |
|
03-May-2018 |
Jakub Kicinski <kuba@kernel.org> |
tools: bpftool: add simple perf event output reader Users of BPF sooner or later discover perf_event_output() helpers and BPF_MAP_TYPE_PERF_EVENT_ARRAY. Dumping this array type is not possible, however, we can add simple reading of perf events. Create a new event_pipe subcommand for maps, this sub command will only work with BPF_MAP_TYPE_PERF_EVENT_ARRAY maps. Parts of the code from samples/bpf/trace_output_user.c. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
e64d5256 |
|
03-May-2018 |
Jakub Kicinski <kuba@kernel.org> |
tools: bpftool: move get_possible_cpus() to common code Move the get_possible_cpus() function to shared code. No functional changes. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
c642ea26 |
|
03-May-2018 |
Jakub Kicinski <kuba@kernel.org> |
tools: bpftool: fold hex keyword in command help Instead of spelling [hex] BYTES everywhere use DATA as keyword for generalized value. This will help us keep the messages concise when longer command are added in the future. It will also be useful once BTF support comes. We will only have to change the definition of DATA. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
0c90f224 |
|
17-Apr-2018 |
Quentin Monnet <quentin@isovalent.com> |
tools: bpftool: make it easier to feed hex bytes to bpftool bpftool uses hexadecimal values when it dumps map contents: # bpftool map dump id 1337 key: ff 13 37 ff value: a1 b2 c3 d4 ff ff ff ff Found 1 element In order to lookup or update values with bpftool, the natural reflex is then to copy and paste the values to the command line, and to try to run something like: # bpftool map update id 1337 key ff 13 37 ff \ value 00 00 00 00 00 00 1a 2b Error: error parsing byte: ff bpftool complains, because it uses strtoul() with a 0 base to parse the bytes, and that without a "0x" prefix, the bytes are considered as decimal values (or even octal if they start with "0"). To feed hexadecimal values instead, one needs to add "0x" prefixes everywhere necessary: # bpftool map update id 1337 key 0xff 0x13 0x37 0xff \ value 0 0 0 0 0 0 0x1a 0x2b To make it easier to use hexadecimal values, add an optional "hex" keyword to put after "key" or "value" to tell bpftool to consider the digits as hexadecimal. We can now do: # bpftool map update id 1337 key hex ff 13 37 ff \ value hex 0 0 0 0 0 0 1a 2b Without the "hex" keyword, the bytes are still parsed according to normal integer notation (decimal if no prefix, or hexadecimal or octal if "0x" or "0" prefix is used, respectively). The patch also add related documentation and bash completion for the "hex" keyword. Suggested-by: Daniel Borkmann <daniel@iogearbox.net> Suggested-by: David Beckett <david.beckett@netronome.com> Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
4b6eca9d |
|
23-Mar-2018 |
Jakub Kicinski <kuba@kernel.org> |
tools: bpftool: don't use hex numbers in JSON output JSON does not accept hex numbers with 0x prefix. Simply print as decimal numbers, JSON should be primarily machine-readable. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Fixes: 831a0aafe5c3 ("tools: bpftool: add JSON output for `bpftool map *` commands") Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
#
a55aaf6d |
|
19-Jan-2018 |
Roman Gushchin <guro@fb.com> |
bpftool: recognize BPF_MAP_TYPE_CPUMAP maps Add BPF_MAP_TYPE_CPUMAP map type to the list of map type recognized by bpftool and define corresponding text representation. Signed-off-by: Roman Gushchin <guro@fb.com> Cc: Quentin Monnet <quentin.monnet@netronome.com> Cc: Jakub Kicinski <jakub.kicinski@netronome.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Alexei Starovoitov <ast@kernel.org> Acked-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
064a07cb |
|
17-Jan-2018 |
Jakub Kicinski <kuba@kernel.org> |
tools: bpftool: report device information for offloaded maps Print the information about device on which map is created. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
6ebe6dbd |
|
02-Jan-2018 |
Jakub Kicinski <kuba@kernel.org> |
tools: bpftool: alias show and list commands iproute2 seems to accept show and list as aliases. Let's do the same thing, and by allowing both bring cgroup syntax back in line with maps and progs. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
8207c6dd |
|
22-Dec-2017 |
Jakub Kicinski <kuba@kernel.org> |
tools: bpftool: protect against races with disappearing objects On program/map show we may get an ID of an object from GETNEXT, but the object may disappear before we call GET_FD_BY_ID. If that happens, ignore the object and continue. Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool") Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
b3b1b653 |
|
22-Dec-2017 |
Jakub Kicinski <kuba@kernel.org> |
tools: bpftool: maps: close json array on error paths of show We can't return from the middle of do_show(), because json_array will not be closed. Break out of the loop. Note that the error handling after the loop depends on errno, so no need to set err. Fixes: 831a0aafe5c3 ("tools: bpftool: add JSON output for `bpftool map *` commands") Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
|
#
c541b734 |
|
07-Nov-2017 |
Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> |
tools: bpftool: optionally show filenames of pinned objects Making it optional to show file names of pinned objects because it scans complete bpf-fs filesystem which is costly. Added option -f|--bpffs. Documentation updated. Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
4990f1f4 |
|
07-Nov-2017 |
Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> |
tools: bpftool: show filenames of pinned objects Added support to show filenames of pinned objects. For example: root@test# ./bpftool prog 3: tracepoint name tracepoint__irq tag f677a7dd722299a3 loaded_at Oct 26/11:39 uid 0 xlated 160B not jited memlock 4096B map_ids 4 pinned /sys/fs/bpf/softirq_prog 4: tracepoint name tracepoint__irq tag ea5dc530d00b92b6 loaded_at Oct 26/11:39 uid 0 xlated 392B not jited memlock 4096B map_ids 4,6 root@test# ./bpftool --json --pretty prog [{ "id": 3, "type": "tracepoint", "name": "tracepoint__irq", "tag": "f677a7dd722299a3", "loaded_at": "Oct 26/11:39", "uid": 0, "bytes_xlated": 160, "jited": false, "bytes_memlock": 4096, "map_ids": [4 ], "pinned": ["/sys/fs/bpf/softirq_prog" ] },{ "id": 4, "type": "tracepoint", "name": "tracepoint__irq", "tag": "ea5dc530d00b92b6", "loaded_at": "Oct 26/11:39", "uid": 0, "bytes_xlated": 392, "jited": false, "bytes_memlock": 4096, "map_ids": [4,6 ], "pinned": [] } ] root@test# ./bpftool map 4: hash name start flags 0x0 key 4B value 16B max_entries 10240 memlock 1003520B pinned /sys/fs/bpf/softirq_map1 5: hash name iptr flags 0x0 key 4B value 8B max_entries 10240 memlock 921600B root@test# ./bpftool --json --pretty map [{ "id": 4, "type": "hash", "name": "start", "flags": 0, "bytes_key": 4, "bytes_value": 16, "max_entries": 10240, "bytes_memlock": 1003520, "pinned": ["/sys/fs/bpf/softirq_map1" ] },{ "id": 5, "type": "hash", "name": "iptr", "flags": 0, "bytes_key": 4, "bytes_value": 8, "max_entries": 10240, "bytes_memlock": 921600, "pinned": [] } ] Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
0641c3c8 |
|
23-Oct-2017 |
Quentin Monnet <quentin@isovalent.com> |
tools: bpftool: update documentation for --json and --pretty usage Update the documentation to provide help about JSON output generation, and add an example in bpftool-prog manual page. Also reintroduce an example that was left aside when the tool was moved from GitHub to the kernel sources, in order to show how to mount the bpffs file system (to pin programs) inside the bpftool-prog manual page. Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
004b45c0 |
|
23-Oct-2017 |
Quentin Monnet <quentin@isovalent.com> |
tools: bpftool: provide JSON output for all possible commands As all commands can now return JSON output (possibly just a "null" value), output of `bpftool --json batch file FILE` should also be fully JSON compliant. Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
9a5ab8bf |
|
23-Oct-2017 |
Quentin Monnet <quentin@isovalent.com> |
tools: bpftool: turn err() and info() macros into functions Turn err() and info() macros into functions. In order to avoid naming conflicts with variables in the code, rename them as p_err() and p_info() respectively. The behavior of these functions is similar to the one of the macros for plain output. However, when JSON output is requested, these macros return a JSON-formatted "error" object instead of printing a message to stderr. To handle error messages correctly with JSON, a modification was brought to their behavior nonetheless: the functions now append a end-of-line character at the end of the message. This way, we can remove end-of-line characters at the end of the argument strings, and not have them in the JSON output. All error messages are formatted to hold in a single call to p_err(), in order to produce a single JSON field. Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
831a0aaf |
|
23-Oct-2017 |
Quentin Monnet <quentin@isovalent.com> |
tools: bpftool: add JSON output for `bpftool map *` commands Reuse the json_writer API introduced in an earlier commit to make bpftool able to generate JSON output on `bpftool map { show | dump | lookup | getnext }` commands. Remaining commands produce no output. Some functions have been spit into plain-output and JSON versions in order to remain readable. Outputs for sample maps have been successfully tested against a JSON validator. Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
d9c0b48d |
|
19-Oct-2017 |
Quentin Monnet <quentin@isovalent.com> |
tools: bpftool: print only one error message on byte parsing failure Make error messages more consistent. Specifically, when bpftool fails at parsing map key bytes, make it print a single error message to stderr and return from the function, instead of (always) printing a second error message afterwards. Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
9cbe1f58 |
|
19-Oct-2017 |
Quentin Monnet <quentin@isovalent.com> |
tools: bpftool: add pointer to file argument to print_hex() Make print_hex() able to print to any file instead of standard output only, and rename it to fprint_hex(). The function can now be called with the info() macro, for example, without splitting the output between standard and error outputs. Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
71bb428f |
|
04-Oct-2017 |
Jakub Kicinski <kuba@kernel.org> |
tools: bpf: add bpftool Add a simple tool for querying and updating BPF objects on the system. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Simon Horman <simon.horman@netronome.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|