libbpf / bpftool Goto Github PK
View Code? Open in Web Editor NEWAutomated upstream mirror for bpftool stand-alone build.
License: Other
Automated upstream mirror for bpftool stand-alone build.
License: Other
make error build in clang 11.0.0 like that:
netlink_dumper.c:50:14: error: use of undeclared identifier 'XDP_ATTACHED_MULTI'
if (mode == XDP_ATTACHED_MULTI) {
^
netlink_dumper.c:55:24: error: use of undeclared identifier 'IFLA_XDP_SKB_PROG_ID'; did you mean 'IFLA_XDP_PROG_ID'?
xdp_dump_prog_id(tb, IFLA_XDP_SKB_PROG_ID, "generic", true);
^~~~~~~~~~~~~~~~~~~~
IFLA_XDP_PROG_ID
maybe miss if_link.h in usersapce?
like add libbpf that https://github.com/libbpf/libbpf/tree/master/include/uapi/linux
bpftool map event_pipe
dumps data from a perf ring. We don't have any equivalent yet for BPF ring buffers.
I have following map:
struct
{
__uint(type, BPF_MAP_TYPE_RINGBUF);
__uint(max_entries, MAX_ENTRIES);
} ring_map SEC(".maps");
under v7.0.0 it works, under v7.1.0 getting an error:
bpftool gen skeleton build/.gens/xxx/android/x86_64/release/rules/bpf/xxx.bpf.o -d -p
...
libbpf: map 'xxx': unsupported map linkage static.
{
"error": "failed to open BPF object file: Operation not supported"
}
I've not checked whether bpftool can dump a map protected by a spinlock, but I suspect it cannot (BPF_F_LOCK
is likely required?). We should check and make it possible if it's not the case.
We should really have a more robust CI for bpftool.
Part of the BPF selftests (and running as part of the BPF CI).
bpftool feature probe
.There is a variety of components that we would like to test. The list below is mostly a brain dump. Ideally, we want as much as possible as this testing to happen as part of the BPF CI, meaning we probably want to upstream it and make it part of the BPF selftests (Or have a dedicated repo for bpftool CI and see with BPF CI folks, to do something similar to libbpf's CI? Maybe for building bpftool, but testing that features work correctly should really go upstream).
Check that all supported program and map types remain supported, by trying to load minimal objects of each type. I had something in progress on a dedicated branch but I never finished it.
Check that most/all commands behave as expected. This will require quite some work, because:
A code coverage tool could be helpful at some point, if we manage to cover a significant portion of the command list.
tests/
and GitHub workflows).bpftool net attach
can load only one XDP program to a network interface. We would make it work in a similar way to what xdp-loader does.
TL;DR: When cross-compiling, host little-endian bootstrap bpftool cannot
open a big-endian ELF to generate a skeleton from it and build target
big-endian bpftool.Long version: Currently, bpftool's Makefile compiles the
skeleton-related programs (skeletons/*.bpf.c) without paying attention
to the target architecture. When cross-compiling, say on a host with LE
for a target with BE, this leads to runtime failure on "bpftool prog
show", because bpftool cannot load the LE bytecode on the BE target
machine. This is Christophe's output here.So the first fix is to make the Makefile aware of the target endianness
somehow, and to build this ELF with target endianness. But this is not
enough, because when (host) boostrap bpftool opens the ELF to generate
the skeleton from it before building the final (target) bpftool binary,
then bpf_object__check_endianness() in libbpf refuses to open the ELF if
endianness is not the same as on the host as seen here.The way I see it, we'd need to make sure libbpf can work with ELFs of a
different endianness -- assuming that's doable -- and to pass it an
option to tell whether LE or BE is expected for a given ELF. Which in
turn would require bootstrap bpftool to be aware of the target
endianness.
Hi,
I compiled the https://github.com/vincentmli/XDPeriments/blob/master/RRL/Round1/xdp_rrl_per_ip.c to xdp_rrl_per_ip.o and also checked out bpftool v6.7.0 and compiled bpftool statically, then trying to load it on legacy old Ubuntu 16.04 with kernel 4.15.0-99, but got following error
./bpftool --legacy prog load xdp_rrl_per_ip.o xdp dev lo
libbpf: map 'state_map' (legacy): legacy map definitions are deprecated, use BTF-defined maps instead
libbpf: map 'state_map_v6' (legacy): legacy map definitions are deprecated, use BTF-defined maps instead
libbpf: map 'state_map': failed to create: Invalid argument(-22)
libbpf: failed to load object 'xdp_rrl_per_ip.o'
Error: failed to load object file
my intention is to run XDP program on the Ubuntu 16.04 kernel without BTF support, the map in the xdp_rrl_per_ip.c
is not BTF defined map, the reason I use bpftool is that I could not find user space bpf loader that would work in Ubuntu 16.04 user space. is there way to workaround this with bpftool? I looked btfhub project, do I really need BTF?
./bpftool --version
./bpftool v6.7.0
using libbpf v0.7
features: libbpf_strict, skeletons
We have bash completion, but many users use Zsh nowadays.
Some other shells are in use as well (fish, ...), and could be candidates, although I'm not familiar with other completion systems.
Not sure if these would make it to the Linux repo, but alternatively we could host them on this mirror at least.
Command bpftool perf list
does not display all perf-related programs. It doesn't show programs attached through BPF links, only those that have an open FD. This should be documented.
In my notes, I also have a mention that writeable tracepoints are not displayed either. Because they use links? Should be investigated and clarified in the documentation.
Add a GitHub workflow to build and publish a new image (likely to ghcr.io) on pushes to the master
branch, so that users can pull it directly.
Following the discussion with Andrii on the BPF mailing list, we want to improve error messages by writing explicitly the name of the error returned from the kernel in addition to its interpretation, for example:
Error: can't get next program: [-EPERM] Operation not permitted
There's some work to do in libbpf (teaching libbpf_strerror_r()
to do this), and then we could wrap error messages in bpftool to use that function.
Extract from man bpftool-map
:
bpftool map create FILE type TYPE key KEY_SIZE value VALUE_SIZE
entries MAX_ENTRIES name NAME [flags FLAGS] [inner_map MAP]
[dev NAME]
bpftool map dump MAP
bpftool map update MAP [key DATA] [value VALUE] [UPDATE_FLAGS]
Instead of passing integer for FLAGS
and UPDATE_FLAGS
that are the sum of all relevant flags, we could support something more user-friendly as well, like a comma-separated list of flags: BPF_F_NO_PREALLOC,BPF_F_RDONLY,...
Few minor improvements to keep tracking:
For human readable output dump "prog id %u" for progs and "link id %u" for links consistently. Currently some types dump just "id %u" and other use "prog_id %u" ("_").
The Documentation/bpftool-net.rst is in some cases overly specific in which order what is dumped (is it relevant for man page?) and examples could need a refresher.
Detection of LLVM libraries for LLVM 16+ fails in the kernel repository, resulting in bpftool being compiled without the LLVM-based disassembler for JIT-compiled BPF programs.
Reported here: https://lore.kernel.org/lkml/CALS7K9V1j6ufrQ=6nGjyHQCWb7-YiqNdctBWk8og1gW_q4C4dA@mail.gmail.com/
See libbpf/ci#101 for context and blocker issue.
The GitHub mirror uses a different probe for LLVM libraries, and is not affected by this issue.
Hi,
I am working on a small tool which needs to identify map type (HASH/ARRAY etc) from bpf programs. I have seen BTF which is able to provide type of the key and value of the map but not the type of the map itself (which is the value of the map type variable).
So what I want to ask is is there a way to identity the type of map being used by looking at the BPF programs.
Not sure if this is the correct place to ask this question, if not please let me know.
Thanks in advance.
https://lore.kernel.org/bpf/[email protected]/
binutils changed the signature of init_disassemble_info(), which now causes
perf and bpftool to fail to compile (e.g. on debian unstable).
Relevant binutils commit: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=60a3da00bd5407f07d64dff82a4dae98230dfaac
util/annotate.c: In function ‘symbol__disassemble_bpf’:
util/annotate.c:1765:9: error: too few arguments to function ‘init_disassemble_info’
1765 | init_disassemble_info(&info, s,
| ^~~~~~~~~~~~~~~~~~~~~
In file included from util/annotate.c:1718:
/usr/include/dis-asm.h:472:13: note: declared here
472 | extern void init_disassemble_info (struct disassemble_info *dinfo, void *stream,
| ^~~~~~~~~~~~~~~~~~~~~
with equivalent failures in
tools/bpf/bpf_jit_disasm.c
tools/bpf/bpftool/jit_disasm.c
This is being discussed on the mailing list. See email thread for more details.
We could add an option to dump inner maps when dumping an outer map-of-map with bpftool.
Some link types could be added here:
Line 198 in 87e2cb7
Side note: Are programs attached to XDP links displayed in bpftool net
?
Code like bpf_printk("hello\n")
will generate a section '.rodata.str1.1'
When I compile the above code with old version bpftool (the bpftool is installed by apt install in Ubuntu 20.10 kernel 5.8), the generated binary works well.
But when I use the same environment with the latest bpftool version to compile the same code, the generated binary report the error "libbpf: failed to find skeleton map '.rodata.str1.1'".
clang \
-I. \
-I/home/ubuntu/bpf/bpftool/include/uapi/ \
-I/home/ubuntu/bpf/bpftool/src/bootstrap/libbpf/include \
-g -O2 -Wall -target bpf -c skeleton/pid_iter.bpf.c -o pid_iter.bpf.o
skeleton/pid_iter.bpf.c:47:14: error: incomplete definition of type 'struct bpf_perf_link'
perf_link = container_of(link, struct bpf_perf_link, link);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I don't think bpftool supports this at the moment.
Building bpftool statically, as explained in the README.md, should work:
CFLAGS=--static
We should:
See discussion in #54.
No need to display an empty maps for types for which we know we can't display anything - apparently the BPF ring buffer, likely the perf event array maps too, maybe a few others. Bpftool should just tell it cannot dump these types.
Hi, I'm trying to compile bpftool in linux kernel 6.3 on ubuntu 22.04. When I do make
I receive the following errors:
~mptcp_net-next/tools/bpf/bpftool$ make
Auto-detecting system features:
... clang-bpf-co-re: [ on ]
... llvm: [ on ]
... libcap: [ OFF ]
... libbfd: [ OFF ]
MKDIR /home/test2/mptcp_net-next/tools/bpf/bpftool/libbpf/
make[1]: enter from the directory '/home/test2/mptcp_net-next/tools/lib/bpf'
GEN /home/test2/mptcp_net-next/tools/bpf/bpftool/libbpf/bpf_helper_defs.h
MKDIR /home/test2/mptcp_net-next/tools/bpf/bpftool/libbpf/staticobjs/
CC /home/test2/mptcp_net-next/tools/bpf/bpftool/libbpf/staticobjs/libbpf.o
In file included from /usr/include/asm-generic/int-ll64.h:12,
from /usr/include/asm-generic/types.h:7,
from /usr/include/x86_64-linux-gnu/asm/types.h:1,
from /home/test2/mptcp_net-next/tools/include/linux/types.h:13,
from /home/test2/mptcp_net-next/tools/include/linux/compiler.h:105,
from /home/test2/mptcp_net-next/tools/include/linux/err.h:5,
from libbpf.c:29:
/home/test2/mptcp_net-next/tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
14 | #error Inconsistent word size. Check asm/bitsperlong.h
| ^~~~~
make[2]: *** [/home/test2/mptcp_net-next/tools/build/Makefile.build:98: /home/test2/mptcp_net-next/tools/bpf/bpftool/libbpf/staticobjs/libbpf.o] Error 1
make[1]: *** [Makefile:157: /home/test2/mptcp_net-next/tools/bpf/bpftool/libbpf/staticobjs/libbpf-in.o] Error 2
make[1]: exits from the directory '/home/test2/mptcp_net-next/tools/lib/bpf'
make: *** [Makefile:46: /home/test2/mptcp_net-next/tools/bpf/bpftool/libbpf/libbpf.a] Error 2
Any advice?
Some prints use argv[0]
as the name of the tool, e.g. bpftool --version
. I don't like that.
I find it weird e.g. that the output should change depending on how you call the tool – via $PATH
or by absolute path. But we even faced a practical issue with that: NixOS/nixpkgs#195934
So I suggest that you consider changing this. You can get inspired in the linked pull request or not.
This is a self-reminder to “revert” torvalds/linux@4b7ef71 (not in the GitHub mirror yet) and replace the /* fallthrough */
comment in btf_dumper.c with the new fallthrough
macro, after its definition is available in bpf-next tree.
Support dumping BPF maps faster by using batch map processing when possible.
The command below can be used to dump the control flow graph on the program:
# bpftool prog dump xlated id <id> visual
(Example)
But as far as I remember (not 100% sure though) we don't have the C code lines on this graph. It would be helpful to have them, to better analyse the code.
Version:
bpftool --version
bpftool v6.7.0
using libbpf v0.7
features: libbpf_strict
This happens only in a 32-bit environment and not 64-bit. I have a BPF array with value that looks like this:
struct map_value {
int a;
int b;
short c;
bool d;
};
struct {
__uint( type, BPF_MAP_TYPE_ARRAY );
__uint( max_entries, 1 );
__type( key, uint32_t );
__type( value, struct map_value );
} my_map SEC( ".maps" );
bpftool map dump shows:
bpftool map dump name my_map --pretty
[{
"key": ["0x00","0x00","0x00","0x00"
],
"value": ["0x00","0x00","0x00","0x00","0x00","0x00","0x00","0x00","0x00","0x00","0x00","0x00"
],
"formatted": {
"key": 0,
"value": {
"a": 0,
"b": 0,
"c": 0,
"d": true
}
}
}
]
The raw bytes look right (this is the initial state of the array) but the formatted output is wrong.
Is there a plan to drop the libbpf submodule, and/or to allow building bpftool against the stand-alone libbpf? Right now this requires modifications to the Makefile, making life of people trying to package bpftool harder than it needs to be. Also, the release tarball does not include libbpf, so it can't be built without extra actions.
If a bpf program has a global variable of type: long, its skeleton will include
a bss map that will have a field for this variable. The long variable in BPF is
64-bit. if we are working on a 32-bit machine, the generated skeleton has to
compile for that machine where long is 32-bit.
More context: https://lore.kernel.org/bpf/CANk7y0joRFw2F4iAuN9r-dWWMvOmbFZz_J4rhGhgVFjdnxPTYw@mail.gmail.com/
root@DESKTOP-H3MBKRR:/home/lys/work/bpf# sudo bpftool prog load hello.o tracepoint
Error: can't mount BPF file system to pin the object (tracepoint): mount --make-private . failed: Invalid argument
is bpftool bug?
Following the instructions in README.md, I used the command
CFLAGS=--static make
hoping to compile and statically link the bpftool binary, however, the error I got it
/usr/bin/ld: cannot find -lelf
/usr/bin/ld: cannot find -lz
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
I'm using a fedora:32 docker container to build. I'm guessing I need to install statically linked versions of libelf, libz and libc? I see libelf.so, libz.so and libc.so are all there in /usr/lib64. Where do I get libelf.a, libz.a, and libc.a? Not very familiar with statically linked libraries. Any help is appreciated!
bpftool btf dump file /sys/kernel/btf/<object>
is valid, but not documented in man bpftool-btf
. The document only mentions that When specifying FILE, an ELF file is expected [...]
. Documentation should be updated.
Someone reported an issue with binutils 2.40 (released mid-January 2023).
Reference: https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:B/bpftool/standard/x86_64
[ 77s] gcc -O2 -W -Wall -Wextra -Wno-unused-parameter
-Wno-missing-field-initializers -Wbad-function-cast
-Wdeclaration-after-statement -Wformat-security -Wformat-y2k -Winit-self
-Wmissing-declarations -Wmissing-prototypes -Wno-system-headers
-Wold-style-definition -Wpacked -Wredundant-decls -Wstrict-prototypes
-Wswitch-default -Wundef -Wwrite-strings -Wformat -Wno-type-limits
-Wstrict-aliasing=3 -Wshadow -DPACKAGE='"bpftool"' -D__EXPORTED_HEADERS__ -I.
-I/home/abuild/rpmbuild/BUILD/tools/bpf/bpftool/libbpf/include
-I/home/abuild/rpmbuild/BUILD/kernel/bpf/
-I/home/abuild/rpmbuild/BUILD/tools/include
-I/home/abuild/rpmbuild/BUILD/tools/include/uapi -DDISASM_FOUR_ARGS_SIGNATURE
-DDISASM_INIT_STYLED -DHAVE_LIBBFD_SUPPORT -DBPFTOOL_WITHOUT_SKELETONS btf.o
btf_dumper.o cfg.o cgroup.o common.o feature.o gen.o iter.o json_writer.o
link.o main.o map.o map_perf_ring.o net.o netlink_dumper.o perf.o pids.o prog.o
struct_ops.o tracelog.o xlated_dumper.o jit_disasm.o disasm.o
/home/abuild/rpmbuild/BUILD/tools/bpf/bpftool/libbpf/libbpf.a -lelf -lz -lbfd
-ldl -lopcodes -liberty -o bpftool
[ 77s] /usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/gcc/x86_64-suse-linux/12/../../../../lib64/libbfd.a(elfxx-x86.o): in function `_bfd_x86_elf_write_sframe_plt':
[ 77s] /home/abuild/rpmbuild/BUILD/binutils-2.40/build-dir/bfd/../../bfd/elfxx-x86.c:1977: undefined reference to `sframe_encoder_write'
[ 77s] /usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: /home/abuild/rpmbuild/BUILD/binutils-2.40/build-dir/bfd/../../bfd/elfxx-x86.c:1983: undefined reference to `sframe_encoder_free'
[ 77s] /usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/gcc/x86_64-suse-linux/12/../../../../lib64/libbfd.a(elfxx-x86.o): in function `_bfd_x86_elf_create_sframe_plt':
[ 77s] /home/abuild/rpmbuild/BUILD/binutils-2.40/build-dir/bfd/../../bfd/elfxx-x86.c:1874: undefined reference to `sframe_encode'
as seen, new binutils comes with a new library called sframe and the
aforementioned issue can be fixed by adding '-lsframe' to the command line.
Sounds like we'll need to add new probes to https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/build/feature/Makefile#n246, and update bpftool's Makefile accordingly.
I don't know if this library comes with binutils-dev or if it needs to be installed separately. I haven't reproduced yet.
Output:
# bpftool feature probe | grep sockopt
eBPF program_type cgroup_sockopt is available
- bpf_setsockopt
- bpf_getsockopt
- bpf_setsockopt
- bpf_getsockopt
eBPF helpers supported for program type cgroup_sockopt:
- bpf_setsockopt
- bpf_getsockopt
Expected output:
# bpftool feature probe | grep sockopt
eBPF program_type cgroup_sockopt is available
- bpf_setsockopt
- bpf_getsockopt
eBPF helpers supported for program type cgroup_sockopt:
Version:
# bpftool --version
bpftool v5.10.140
Kernel Version:
# uname -r
5.10.0-14-amd64
The helper bpf_getsockopt
did not get merged into kernel until 5.12 due to my research. Cilium is using bpftool to check whether this helper exist. On kernel 5.10, bpftool show this helper exist, so cilium tries to use this helper and crashed because it does not exist. I tried bpftool on kernel 5.4.214, it correctly show the absence of the helper.
I'm seeing this error in some of our autobuilders test builds. I verified this error still exists as of version 51d4a12.
net.c: In function 'netlink_open':
net.c:110:36: error: 'NETLINK_EXT_ACK' undeclared (first use in this function); did you mean 'NETLINK_CAP_ACK'?
110 | if (setsockopt(sock, SOL_NETLINK, NETLINK_EXT_ACK,
| ^~~~~~~~~~~~~~~
| NETLINK_CAP_ACK
From man bpftool-btf
:
BTF_SRC := { id BTF_ID | prog PROG | map MAP [{key | value | kv | all}] | file FILE }
We could support passing BTF objects by name
as well, e.g. vmlinux
or any module name.
This is gonna ruin the git blame
, but we should really look into fixing the weird indentation in use for the detailed description of the commands in the doc. We currently have two tabs followed by two spaces for the body of the description, auto-indent in text editors don't like it and it's a pain for contributors.
I'm not aware of any particular reason for that other than that's how the doc was created in the first place.
Maybe just two tabs, or maybe just spaces - whatever. We need to make sure that the formatting of the rendered man page is preserved, though.
Similarly to what we do for program types, map types, helpers, and a few other components, we could look into dumping supported kfuncs
with bpftool feature probe
.
It is not clear yet what the probes would look like.
Seems like there is a minor issue in Makefile.feature:
make feature-libbfd=0 feature-libbfd-liberty=0 feature-libbfd-liberty-z=0
Makefile.feature:41: *** missing separator. Stop.
The following change fixes it:
--- Makefile.feature.orig 2022-05-20 11:16:43.241156473 -0700
+++ Makefile.feature 2022-05-20 11:17:33.380310301 -0700
@@ -38,8 +38,8 @@
feature-libbfd-liberty := \
$(findstring 1,$(call libbfd_build,-lbfd -ldl -liberty))
ifneq ($(feature-libbfd-liberty),1)
- $(findstring 1,feature-libbfd-liberty-z := \
- $(call libbfd_build,-lbfd -ldl -liberty -lz))
+ feature-libbfd-liberty-z := \
+ $(findstring 1,$(call libbfd_build,-lbfd -ldl -liberty -lz))
endif
endif
HAS_LIBBFD := $(findstring 1, \
On Ubuntu focal I see:
$ make
... libbfd: [ on ]
... disassembler-four-args: [ on ]
... zlib: [ on ]
... libcap: [ on ]
... clang-bpf-co-re: [ OFF ]
After looking in Makefile.features it is looking for BTF_KIND_VAR, but I don't see that:
$ clang --version
clang version 10.0.0-4ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
[~/scm/bpftool/src (master)]
$ printf '%s\n' 'struct s { int i; } __attribute__((preserve_access_index)); struct s foo;' | clang -g -target bpf -S -o - -x c - | grep BTF_KIND_
.long 1 # BTF_KIND_STRUCT(id = 1)
.long 5 # BTF_KIND_INT(id = 2)
Am I not configured correctly or should this check be more loose?
Makefile.feature may check requirement lib like as zlib,but if clang's version 11.0.0 it's not work well.
some code need escape character like \n
you need add like that:
- $(shell echo $(ZLIB_PROBE) | \
+ $(shell echo -e $(ZLIB_PROBE) | \
$(CC) $(CFLAGS) -Wall -Werror $(LDFLAGS) -x c - -lz -S -o - >/dev/null 2>&1 \
&& echo 1)
or it output error like that:
<stdin>:1:18: error: extra tokens at end of #include directive [-Werror,-Wextra-tokens]
#include <zlib.h>\n int main(void) { z_stream zs; inflateInit(&zs); return 0; }
^
//
1 error generated.
and other echo
need echo -e
replace
Makefile.include need add EXTRA_WARNINGS in clang version is 11.0.0
+ -Wno-unused-command-line-argument \
Context: https://lore.kernel.org/bpf/[email protected]/T/#t
Function mount_bpffs_for_pin()
was initially written for getting files as arguments, so it tries to mount (when relevant) the bpffs on the parent directory of the file it gets.
When receiving a directory name instead, it still uses the parent directory, when it should instead:
bpftool iter
only support the pin
subcommands. It begs for a list
subcommands. Not sure if this is completely necessary though, given that we can already see the iterators from bpftool prog
. At least we've got the code for listing them already: if we want to add a bpftool iter list
we can probably just reuse the code from bpftool prog list
, filtering on program type.
Attach types are using the legacy attach type names, but we switched to those used by libbpf in commit torvalds/linux@1ba5ad3. (Legacy attach type names are only kept for compatibility but are not longer recommended.) We should update the attach types in the doc.
Lines 235 to 245 in 43b5daa
prog_attach_flags
is the latest field in uapi but not exist in older kernelprog_cnt
) must be zero
/* helper macro to check that unused fields 'union bpf_attr' are zero */
#define CHECK_ATTR(CMD) \
memchr_inv((void *) &attr->CMD##_LAST_FIELD + \
sizeof(attr->CMD##_LAST_FIELD), 0, \
sizeof(*attr) - \
offsetof(union bpf_attr, CMD##_LAST_FIELD) - \
sizeof(attr->CMD##_LAST_FIELD)) != NULL
#define BPF_PROG_QUERY_LAST_FIELD query.prog_cnt
static int bpf_prog_query(const union bpf_attr *attr,
union bpf_attr __user *uattr)
{
if (!capable(CAP_NET_ADMIN))
return -EPERM;
if (CHECK_ATTR(BPF_PROG_QUERY))
return -EINVAL;
...
}
It seems the upstream kernel doesn't have the compatibility issue because libbpf/bpftool is as the part of it's source.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.