aboutsummaryrefslogtreecommitdiffstats
path: root/include/uapi/linux/if_plip.h (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2019-01-25xsk: add sock_diag interface for AF_XDPBjörn Töpel6-5/+285
This patch adds the sock_diag interface for querying sockets from user space. Tools like iproute2 ss(8) can use this interface to list open AF_XDP sockets. The user-space ABI is defined in linux/xdp_diag.h and includes netlink request and response structs. The request can query sockets and the response contains socket information about the rings, umems, inode and more. Signed-off-by: Björn Töpel <bjorn.topel@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-01-25xsk: add id to umemBjörn Töpel2-0/+14
This commit adds an id to the umem structure. The id uniquely identifies a umem instance, and will be exposed to user-space via the socket monitoring interface. Signed-off-by: Björn Töpel <bjorn.topel@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-01-25net: xsk: track AF_XDP sockets on a per-netns listBjörn Töpel3-0/+47
Track each AF_XDP socket in a per-netns list. This will be used later by the sock_diag interface for querying sockets from userspace. Signed-off-by: Björn Töpel <bjorn.topel@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-01-25selftests/bpf: suppress readelf stderr when probing for BTF supportStanislav Fomichev1-1/+2
Before: $ make -s -C tools/testing/selftests/bpf readelf: Error: Missing knowledge of 32-bit reloc types used in DWARF sections of machine number 247 readelf: Warning: unable to apply unsupported reloc type 10 to section .debug_info readelf: Warning: unable to apply unsupported reloc type 1 to section .debug_info readelf: Warning: unable to apply unsupported reloc type 10 to section .debug_info After: $ make -s -C tools/testing/selftests/bpf v2: * use llvm-readelf instead of redirecting binutils' readelf stderr to /dev/null Signed-off-by: Stanislav Fomichev <sdf@google.com> Acked-by: Song Liu <songliubraving@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-01-24bpf: allow BPF programs access skb_shared_info->gso_segs fieldEric Dumazet4-0/+59
This adds the ability to read gso_segs from a BPF program. v3: Use BPF_REG_AX instead of BPF_REG_TMP for the temporary register, as suggested by Martin. v2: refined Eddie Hao patch to address Alexei feedback. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Eddie Hao <eddieh@google.com> Cc: Martin KaFai Lau <kafai@fb.com> Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-01-24bpftool: feature probing, change default actionPrashant Bhole1-1/+1
When 'bpftool feature' is executed it shows incorrect help string. test# bpftool feature Usage: bpftool bpftool probe [COMPONENT] [macros [prefix PREFIX]] bpftool bpftool help COMPONENT := { kernel | dev NAME } Instead of fixing the help text by tweaking argv[] indices, this patch changes the default action to 'probe'. It makes the behavior consistent with other subcommands, where first subcommand without extra parameter results in 'show' action. Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-01-23nfp: bpf: support removing dead codeJakub Kicinski3-1/+34
Add a verifier callback to the nfp JIT to remove the instructions the verifier deemed to be dead. 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>
2019-01-23nfp: bpf: support optimizing dead branchesJakub Kicinski3-0/+49
Verifier will now optimize out branches to dead code, implement the replace_insn callback to take advantage of that optimization. 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>
2019-01-23nfp: bpf: save original program lengthJakub Kicinski4-14/+15
Instead of passing env->prog->len around, and trying to adjust for optimized out instructions just save the initial number of instructions in struct nfp_prog. 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>
2019-01-23nfp: bpf: split up the skip flagJakub Kicinski2-19/+26
We fail program loading if jump lands on a skipped instruction. This is for historical reasons, it used to be that we only skipped instructions optimized out based on prior context, and therefore the optimization would be buggy if we jumped directly to such instruction (because the context would be skipped by the jump). There are cases where instructions can be skipped without any context, for example there is no point in generating code for: r0 |= 0 We will also soon support dropping dead code, so make the skip logic differentiate between "optimized with preceding context" vs other skip types. 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>
2019-01-23nfp: bpf: don't use instruction number for jump targetJakub Kicinski1-1/+1
Instruction number is meaningless at code gen phase. The target of the instruction is overwritten by nfp_fixup_branches(). The convention is to put the raw offset in target address as a place holder. See cmp_* functions. 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>
2019-01-23bpf: notify offload JITs about optimizationsJakub Kicinski4-0/+53
Let offload JITs know when instructions are replaced and optimized out, so they can update their state appropriately. The optimizations are best effort, if JIT returns an error from any callback verifier will stop notifying it as state may now be out of sync, but the verifier continues making progress. 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>
2019-01-23bpf: verifier: record original instruction indexJakub Kicinski2-3/+6
The communication between the verifier and advanced JITs is based on instruction indexes. We have to keep them stable throughout the optimizations otherwise referring to a particular instruction gets messy quickly. 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>
2019-01-23selftests: bpf: add tests for dead code removalJakub Kicinski2-7/+549
Add tests for newly added dead code elimination. Both verifier and BTF tests are added. BTF test infrastructure has to be extended to be able to account for line info which is eliminated during dead code removal. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-23bpf: verifier: remove unconditional branches by 0Jakub Kicinski1-0/+23
Unconditional branches by 0 instructions are basically noops but they can result from earlier optimizations, e.g. a conditional jumps which would never be taken or a conditional jump around dead code. Remove those branches. v0.2: - s/opt_remove_dead_branches/opt_remove_nops/ (Jiong). Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Jiong Wang <jiong.wang@netronome.com> Acked-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-23bpf: verifier: remove dead codeJakub Kicinski3-3/+186
Instead of overwriting dead code with jmp -1 instructions remove it completely for root. Adjust verifier state and line info appropriately. v2: - adjust func_info (Alexei); - make sure first instruction retains line info (Alexei). v4: (Yonghong) - remove unnecessary if (!insn to remove) checks; - always keep last line info if first live instruction lacks one. v5: (Martin Lau) - improve and clarify comments. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-23bpf: verifier: hard wire branches to dead codeJakub Kicinski1-2/+43
Loading programs with dead code becomes more and more common, as people begin to patch constants at load time. Turn conditional jumps to unconditional ones, to avoid potential branch misprediction penalty. This optimization is enabled for privileged users only. For branches which just fall through we could just mark them as not seen and have dead code removal take care of them, but that seems less clean. v0.2: - don't call capable(CAP_SYS_ADMIN) twice (Jiong). v3: - fix GCC warning; Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-23bpf: change parameters of call/branch offset adjustmentJakub Kicinski1-19/+21
In preparation for code removal change parameters to branch and call adjustment functions to be more universal. The current parameters assume we are patching a single instruction with a longer set. A diagram may help reading the change, this is for the patch single case, patching instruction 1 with a replacement of 4: ____ 0 |____| 1 |____| <-- pos ^ 2 | | <-- end old ^ | 3 | | | delta | len 4 |____| | | (patch region) 5 | | <-- end new v v 6 |____| end_old = pos + 1 end_new = pos + delta + 1 If we are before the patch region - curr variable and the target are fully in old coordinates (hence comparing against end_old). If we are after the region curr is in new coordinates (hence the comparison to end_new) but target is in mixed coordinates, so we just check if it falls before end_new, and if so it needs the adjustment. Note that we will not fix up branches which land in removed region in case of removal, which should be okay, as we are only going to remove dead code. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-23selftests/bpf: don't hardcode iptables/nc path in test_tcpnotify_userStanislav Fomichev1-3/+3
system() is calling shell which should find the appropriate full path via $PATH. On some systems, full path to iptables and/or nc might be different that we one we have hardcoded. Signed-off-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-01-23libbpf: Show supported ELF section names when failing to guess prog/attach typeTaeung Song3-12/+48
We need to let users check their wrong ELF section name with proper ELF section names when they fail to get a prog/attach type from it. Because users can't realize libbpf guess prog/attach types from given ELF section names. For example, when a 'cgroup' section name of a BPF program is used, show available ELF section names(types). Before: $ bpftool prog load bpf-prog.o /sys/fs/bpf/prog1 Error: failed to guess program type based on ELF section name cgroup After: libbpf: failed to guess program type based on ELF section name 'cgroup' libbpf: supported section(type) names are: socket kprobe/ kretprobe/ classifier action tracepoint/ raw_tracepoint/ xdp perf_event lwt_in lwt_out lwt_xmit lwt_seg6local cgroup_skb/ingress cgroup_skb/egress cgroup/skb cgroup/sock cgroup/post_bind4 cgroup/post_bind6 cgroup/dev sockops sk_skb/stream_parser sk_skb/stream_verdict sk_skb sk_msg lirc_mode2 flow_dissector cgroup/bind4 cgroup/bind6 cgroup/connect4 cgroup/connect6 cgroup/sendmsg4 cgroup/sendmsg6 Signed-off-by: Taeung Song <treeze.taeung@gmail.com> Cc: Quentin Monnet <quentin.monnet@netronome.com> Cc: Jakub Kicinski <jakub.kicinski@netronome.com> Cc: Andrey Ignatov <rdna@fb.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-01-22bpf: btf: add btf documentationYonghong Song2-0/+877
This patch added documentation for BTF (BPF Debug Format). The document is placed under linux:Documentation/bpf directory. Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-22tools: bpftool: add bash completion for bpftool probesQuentin Monnet1-0/+19
Add the bash completion related to the newly introduced "bpftool feature probe" command. 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>
2019-01-22tools: bpftool: add probes for a network deviceQuentin Monnet2-14/+73
bpftool gained support for probing the current system in order to see what program and map types, and what helpers are available on that system. This patch adds the possibility to pass an interface index to libbpf (and hence to the kernel) when trying to load the programs or to create the maps, in order to see what items a given network device can support. A new keyword "dev <ifname>" can be used as an alternative to "kernel" to indicate that the given device should be tested. If no target ("dev" or "kernel") is specified bpftool defaults to probing the kernel. Sample output: # bpftool -p feature probe dev lo { "syscall_config": { "have_bpf_syscall": true }, "program_types": { "have_sched_cls_prog_type": false, "have_xdp_prog_type": false }, ... } As the target is a network device, /proc/ parameters and kernel configuration are NOT dumped. Availability of the bpf() syscall is still probed, so we can return early if that syscall is not usable (since there is no point in attempting the remaining probes in this case). Among the program types, only the ones that can be offloaded are probed. All map types are probed, as there is no specific rule telling which one could or could not be supported by a device in the future. All helpers are probed (but only for offload-able program types). Caveat: as bpftool does not attempt to attach programs to the device at the moment, probes do not entirely reflect what the device accepts: typically, for Netronome's nfp, results will announce that TC cls offload is available even if support has been deactivated (with e.g. ethtool -K eth1 hw-tc-offload off). v2: - All helpers are probed, whereas previous version would only probe the ones compatible with an offload-able program type. This is because we do not keep a default compatible program type for each helper anymore. 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>
2019-01-22tools: bpftool: add C-style "#define" output for probesQuentin Monnet2-30/+133
Make bpftool able to dump a subset of the parameters collected by probing the system as a listing of C-style #define macros, so that external projects can reuse the result of this probing and build BPF-based project in accordance with the features available on the system. The new "macros" keyword is used to select this output. An additional "prefix" keyword is added so that users can select a custom prefix for macro names, in order to avoid any namespace conflict. Sample output: # bpftool feature probe kernel macros prefix FOO_ /*** System call availability ***/ #define FOO_HAVE_BPF_SYSCALL /*** eBPF program types ***/ #define FOO_HAVE_SOCKET_FILTER_PROG_TYPE #define FOO_HAVE_KPROBE_PROG_TYPE #define FOO_HAVE_SCHED_CLS_PROG_TYPE ... /*** eBPF map types ***/ #define FOO_HAVE_HASH_MAP_TYPE #define FOO_HAVE_ARRAY_MAP_TYPE #define FOO_HAVE_PROG_ARRAY_MAP_TYPE ... /*** eBPF helper functions ***/ /* * Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name) * to determine if <helper_name> is available for <prog_type_name>, * e.g. * #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect) * // do stuff with this helper * #elif * // use a workaround * #endif */ #define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \ FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper ... #define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0 #define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1 #define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1 ... v3: - Change output for helpers again: add a HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell if <helper> is available for program <type>. v2: - #define-based output added as a distinct patch. - "HAVE_" prefix appended to macro names. - Output limited to bpf() syscall availability, BPF prog and map types, helper functions. In this version kernel config options, procfs parameter or kernel version are intentionally left aside. - Following the change on helper probes, format for helper probes in this output style has changed (now a list of compatible program types). 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>
2019-01-22tools: bpftool: add probes for eBPF helper functionsQuentin Monnet5-0/+121
Similarly to what was done for program types and map types, add a set of probes to test the availability of the different eBPF helper functions on the current system. For each known program type, all known helpers are tested, in order to establish a compatibility matrix. Output is provided as a set of lists of available helpers, one per program type. Sample output: # bpftool feature probe kernel ... Scanning eBPF helper functions... eBPF helpers supported for program type socket_filter: - bpf_map_lookup_elem - bpf_map_update_elem - bpf_map_delete_elem ... eBPF helpers supported for program type kprobe: - bpf_map_lookup_elem - bpf_map_update_elem - bpf_map_delete_elem ... # bpftool --json --pretty feature probe kernel { ... "helpers": { "socket_filter_available_helpers": ["bpf_map_lookup_elem", \ "bpf_map_update_elem","bpf_map_delete_elem", ... ], "kprobe_available_helpers": ["bpf_map_lookup_elem", \ "bpf_map_update_elem","bpf_map_delete_elem", ... ], ... } } v5: - In libbpf.map, move global symbol to the new LIBBPF_0.0.2 section. v4: - Use "enum bpf_func_id" instead of "__u32" in bpf_probe_helper() declaration for the type of the argument used to pass the id of the helper to probe. - Undef BPF_HELPER_MAKE_ENTRY after using it. v3: - Do not pass kernel version from bpftool to libbpf probes (kernel version for testing program with kprobes is retrieved directly from libbpf). - Dump one list of available helpers per program type (instead of one list of compatible program types per helper). v2: - Move probes from bpftool to libbpf. - Test all program types for each helper, print a list of working prog types for each helper. - Fall back on include/uapi/linux/bpf.h for names and ids of helpers. - 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>
2019-01-22tools: bpftool: add probes for eBPF map typesQuentin Monnet6-1/+118
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>
2019-01-22tools: bpftool: add probes for eBPF program typesQuentin Monnet5-2/+159
Introduce probes for supported BPF program types in libbpf, and call it from bpftool to test what types are available on the system. The probe simply consists in loading a very basic program of that type and see if the verifier complains or not. Sample output: # bpftool feature probe kernel ... Scanning eBPF program types... eBPF program_type socket_filter is available eBPF program_type kprobe is available eBPF program_type sched_cls is available ... # bpftool --json --pretty feature probe kernel { ... "program_types": { "have_socket_filter_prog_type": true, "have_kprobe_prog_type": true, "have_sched_cls_prog_type": true, ... } } v5: - In libbpf.map, move global symbol to a new LIBBPF_0.0.2 section. - Rename (non-API function) prog_load() as probe_load(). v3: - Get kernel version for checking kprobes availability from libbpf instead of from bpftool. Do not pass kernel_version as an argument when calling libbpf probes. - Use a switch with all enum values for setting specific program parameters just before probing, so that gcc complains at compile time (-Wswitch-enum) if new prog types were added to the kernel but libbpf was not updated. - Add a comment in libbpf.h about setrlimit() usage to allow many consecutive probe attempts. 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>
2019-01-22tools: bpftool: add probes for kernel configuration optionsQuentin Monnet1-0/+182
Add probes to dump a number of options set (or not set) for compiling the kernel image. These parameters provide information about what BPF components should be available on the system. A number of them are not directly related to eBPF, but are in fact used in the kernel as conditions on which to compile, or not to compile, some of the eBPF helper functions. Sample output: # bpftool feature probe kernel Scanning system configuration... ... CONFIG_BPF is set to y CONFIG_BPF_SYSCALL is set to y CONFIG_HAVE_EBPF_JIT is set to y ... # bpftool --pretty --json feature probe kernel { "system_config": { ... "CONFIG_BPF": "y", "CONFIG_BPF_SYSCALL": "y", "CONFIG_HAVE_EBPF_JIT": "y", ... } } v5: - Declare options[] array in probe_kernel_image_config() as static. v4: - Add some options to the list: - CONFIG_TRACING - CONFIG_KPROBE_EVENTS - CONFIG_UPROBE_EVENTS - CONFIG_FTRACE_SYSCALLS - Add comments about those options in the source code. v3: - Add a comment about /proc/config.gz not being supported as a path for the config file at this time. - Use p_info() instead of p_err() on failure to get options from config file, as bpftool keeps probing other parameters and that would possibly create duplicate "error" entries for JSON. v2: - Remove C-style macros output from this patch. - NOT addressed: grouping of those config options into subsections (I don't see an easy way of grouping them at the moment, please see also the discussion on v1 thread). 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>
2019-01-22tools: bpftool: add probes for /proc/ eBPF parametersQuentin Monnet1-0/+187
Add a set of probes to dump the eBPF-related parameters available from /proc/: availability of bpf() syscall for unprivileged users, JIT compiler status and hardening status, kallsyms exports status. Sample output: # bpftool feature probe kernel Scanning system configuration... bpf() syscall for unprivileged users is enabled JIT compiler is disabled JIT compiler hardening is disabled JIT compiler kallsyms exports are disabled Global memory limit for JIT compiler for unprivileged users \ is 264241152 bytes ... # bpftool --json --pretty feature probe kernel { "system_config": { "unprivileged_bpf_disabled": 0, "bpf_jit_enable": 0, "bpf_jit_harden": 0, "bpf_jit_kallsyms": 0, "bpf_jit_limit": 264241152 }, ... } These probes are skipped if procfs is not mounted. v4: - Add bpf_jit_limit parameter. v2: - 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>
2019-01-22tools: bpftool: add basic probe capability, probe syscall availabilityQuentin Monnet10-1/+200
Add a new component and command for bpftool, in order to probe the system to dump a set of eBPF-related parameters so that users can know what features are available on the system. Parameters are dumped in plain or JSON output (with -j/-p options). The current patch introduces probing of one simple parameter: availability of the bpf() system call. Later commits will add other probes. Sample output: # bpftool feature probe kernel Scanning system call availability... bpf() syscall is available # bpftool --json --pretty feature probe kernel { "syscall_config": { "have_bpf_syscall": true } } The optional "kernel" keyword enforces probing of the current system, which is the only possible behaviour at this stage. It can be safely omitted. The feature comes with the relevant man page, but bash completion will come in a dedicated commit. v3: - Do not probe kernel version. Contrarily to what is written below for v2, we can have the kernel version retrieved in libbpf instead of bpftool (in the patch adding probing for program types). v2: - Remove C-style macros output from this patch. - Even though kernel version is no longer needed for testing kprobes availability, note that we still collect it in this patch so that bpftool gets able to probe (in next patches) older kernels as well. 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>
2019-01-17bpf: fix a (false) compiler warningPeter Oskolkov1-1/+2
An older GCC compiler complains: kernel/bpf/verifier.c: In function 'bpf_check': kernel/bpf/verifier.c:4***:13: error: 'prev_offset' may be used uninitialized in this function [-Werror=maybe-uninitialized] } else if (krecord[i].insn_offset <= prev_offset) { ^ kernel/bpf/verifier.c:4***:38: note: 'prev_offset' was declared here u32 i, nfuncs, urec_size, min_size, prev_offset; Although the compiler is wrong here, the patch makes sure that prev_offset is always initialized, just to silence the warning. v2: fix a spelling error in the commit message. Signed-off-by: Peter Oskolkov <posk@google.com> Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-01-17bpftool: add bash completion for peek/push/enqueue/pop/dequeueStanislav Fomichev1-18/+73
bpftool map peek id <TAB> - suggests only queue and stack map ids bpftool map pop id <TAB> - suggests only stack map ids bpftool map dequeue id <TAB> - suggests only queue map ids bpftool map push id <TAB> - suggests only stack map ids bpftool map enqueue id <TAB> - suggests only queue map ids bpftool map push id 1 <TAB> - suggests 'value', not 'key' bpftool map enqueue id 2 <TAB> - suggests 'value', not 'key' bpftool map update id <stack/queue type> - suggests 'value', not 'key' bpftool map lookup id <stack/queue type> - suggests nothing Signed-off-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-01-17bpftool: add pop and dequeue commandsStanislav Fomichev2-35/+98
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>
2019-01-17bpftool: add push and enqueue commandsStanislav Fomichev2-1/+14
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>
2019-01-17bpftool: add peek commandStanislav Fomichev2-1/+7
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>
2019-01-17bpftool: don't print empty key/value for mapsStanislav Fomichev1-19/+28
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>
2019-01-17bpftool: make key optional in lookup commandStanislav Fomichev2-9/+5
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>
2019-01-17bpftool: make key and value optional in update commandStanislav Fomichev2-9/+31
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>
2019-01-16tools/bpf: support __int128 in bpftool map pretty dumperYonghong Song1-12/+86
For formatted output, currently when json is enabled, the decimal number is required. Similar to kernel bpffs printout, for int128 numbers, only hex numbers are dumped, which are quoted as strings. The below is an example to show plain and json pretty print based on the map in test_btf pretty print test. $ bpftool m s 75: hash name pprint_test_has flags 0x0 key 4B value 112B max_entries 4 memlock 4096B $ bpftool m d id 75 ...... { "key": 3, "value": { "ui32": 3, "ui16": 0, "si32": -3, "unused_bits2a": 0x3, "bits28": 0x3, "unused_bits2b": 0x3, "": { "ui64": 3, "ui8a": [3,0,0,0,0,0,0,0 ] }, "aenum": 3, "ui32b": 4, "bits2c": 0x1, "si128a": 0x3, "si128b": 0xfffffffd, "bits3": 0x3, "bits80": 0x10000000000000003, "ui128": 0x20000000000000003 } }, ...... $ bptfool -p -j m d id 75 ...... { "key": ["0x03","0x00","0x00","0x00" ], "value": ["0x03","0x00","0x00","0x00","0x00","0x00","0x00","0x00", "0xfd","0xff","0xff","0xff","0x0f","0x00","0x00","0xc0", "0x03","0x00","0x00","0x00","0x00","0x00","0x00","0x00", "0x03","0x00","0x00","0x00","0x04","0x00","0x00","0x00", "0x01","0x00","0x00","0x00","0x00","0x00","0x00","0x00", "0x00","0x00","0x00","0x00","0x00","0x00","0x00","0x00", "0x03","0x00","0x00","0x00","0x00","0x00","0x00","0x00", "0x00","0x00","0x00","0x00","0x00","0x00","0x00","0x00", "0xfd","0xff","0xff","0xff","0x00","0x00","0x00","0x00", "0x00","0x00","0x00","0x00","0x00","0x00","0x00","0x00", "0x1b","0x00","0x00","0x00","0x00","0x00","0x00","0x00", "0x08","0x00","0x00","0x00","0x00","0x00","0x00","0x00", "0x03","0x00","0x00","0x00","0x00","0x00","0x00","0x00", "0x02","0x00","0x00","0x00","0x00","0x00","0x00","0x00" ], "formatted": { "key": 3, "value": { "ui32": 3, "ui16": 0, "si32": -3, "unused_bits2a": "0x3", "bits28": "0x3", "unused_bits2b": "0x3", "": { "ui64": 3, "ui8a": [3,0,0,0,0,0,0,0 ] }, "aenum": 3, "ui32b": 4, "bits2c": "0x1", "si128a": "0x3", "si128b": "0xfffffffd", "bits3": "0x3", "bits80": "0x10000000000000003", "ui128": "0x20000000000000003" } } } ...... Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-01-16tools/bpf: add bpffs pretty print test for int128Yonghong Song1-0/+79
The bpffs pretty print test is extended to cover int128 types. Tested on an x64 machine. $ test_btf -p ...... BTF pretty print array(#3)......OK PASS:9 SKIP:0 FAIL:0 Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-01-16tools/bpf: refactor test_btf pretty printing for multiple map value formatsYonghong Song1-37/+75
The test_btf pretty print is refactored in order to easily support multiple map value formats. The next patch will add __int128 type tests which needs macro guard __SIZEOF_INT128__. There is no functionality change with this patch. Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-01-16tools/bpf: add int128 raw test in test_btfYonghong Song1-0/+93
Several int128 raw type tests are added to test_btf. Currently these tests are enabled only for x64 and arm64 for which kernel has CONFIG_ARCH_SUPPORTS_INT128 set. $ test_btf ...... BTF raw test[106] (128-bit int): OK BTF raw test[107] (struct, 128-bit int member): OK BTF raw test[108] (struct, 120-bit int member bitfield): OK BTF raw test[109] (struct, kind_flag, 128-bit int member): OK BTF raw test[110] (struct, kind_flag, 120-bit int member bitfield): OK ...... Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-01-16bpf: btf: support 128 bit integer typeYonghong Song1-19/+85
Currently, btf only supports up to 64-bit integer. On the other hand, 128bit support for gcc and clang has existed for a long time. For example, both gcc 4.8 and llvm 3.7 supports types "__int128" and "unsigned __int128" for virtually all 64bit architectures including bpf. The requirement for __int128 support comes from two areas: . bpf program may use __int128. For example, some bcc tools (https://github.com/iovisor/bcc/tree/master/tools), mostly tcp v6 related, tcpstates.py, tcpaccept.py, etc., are using __int128 to represent the ipv6 addresses. . linux itself is using __int128 types. Hence supporting __int128 type in BTF is required for vmlinux BTF, which will be used by "compile once and run everywhere" and other projects. For 128bit integer, instead of base-10, hex numbers are pretty printed out as large decimal number is hard to decipher, e.g., for ipv6 addresses. Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-01-16libbpf: don't define CC and ARStanislav Fomichev1-16/+1
We are already including tools/scripts/Makefile.include which correctly handles CROSS_COMPILE, no need to define our own vars. See related commit 7ed1c1901fe5 ("tools: fix cross-compile var clobbering") for more details. Signed-off-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-01-16networking: Documentation: fix snmp_counters.rst Sphinx warningsRandy Dunlap1-27/+86
Fix over 100 documentation warnings in snmp_counter.rst by extending the underline string lengths and inserting a blank line after bullet items. Examples: Documentation/networking/snmp_counter.rst:1: WARNING: Title overline too short. Documentation/networking/snmp_counter.rst:14: WARNING: Bullet list ends without a blank line; unexpected unindent. Fixes: 2b96547223e3 ("add document for TCP OFO, PAWS and skip ACK counters") Fixes: 8e2ea53a83df ("add snmp counters document") Fixes: 712ee16c230f ("add documents for snmp counters") Fixes: 80cc49507ba4 ("net: Add part of TCP counts explanations in snmp_counters.rst") Fixes: b08794a922c4 ("documentation of some IP/ICMP snmp counters") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: yupeng <yupeng0921@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-01-16net, decnet: use struct_size() in kzalloc()Gustavo A. R. Silva1-1/+1
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; instance = kzalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL); This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-01-16mlxsw: spectrum_nve: Use struct_size() in kzalloc()Gustavo A. R. Silva1-2/+2
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; instance = kzalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL); This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-01-16mlxsw: spectrum_acl_bloom_filter: use struct_size() in kzalloc()Gustavo A. R. Silva1-2/+2
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; void *entry[]; }; instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL); This issue was detected with the help of Coccinelle. Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-01-15dt-bindings: net: dsa: ksz9477: fix indentation for switch spi bindingsSergio Paracuellos1-51/+51
Switch bindings for spi managed mode are using spaces instead of tabs. Fix them to get a file with a proper kernel indentation style. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-01-15Fix ERROR:do not initialise statics to 0 in af_vsock.cLepton Wu1-1/+1
Found by scripts/checkpatch.pl Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.