- Jan 05, 2022
-
-
Jiri Olsa authored
There's another compilation fail (first here [1]) reported by kernel test robot for W=1 clang build: >> samples/ftrace/ftrace-direct-multi-modify.c:7:6: warning: no previous prototype for function 'my_direct_func1' [-Wmissing-prototypes] void my_direct_func1(unsigned long ip) Direct functions in ftrace direct sample modules need to have prototypes defined. They are already global in order to be visible for the inline assembly, so there's no problem. The kernel test robot reported just error for ftrace-direct-multi-modify, but I got same errors also for the rest of the modules touched by this patch. [1] 67d4f6e3 ftrace/samples: Add missing prototype for my_direct_func Link: https://lkml.kernel.org/r/20211219135317.212430-1-jolsa@kernel.org Reported-by:
kernel test robot <lkp@intel.com> Fixes: e1067a07 ("ftrace/samples: Add module to test multi direct modify interface") Fixes: ae0cc3b7 ("ftrace/samples: Add a sample module that implements modify_ftrace_direct()") Fixes: 156473a0 ("ftrace: Add another example of register_ftrace_direct() use case") Fixes: b06457c8 ("ftrace: Add sample module that uses register_ftrace_direct()") Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org>
-
- Dec 09, 2021
-
-
Jiri Olsa authored
Adding ftrace-direct-multi-modify.ko kernel module that uses modify_ftrace_direct_multi API. The core functionality is taken from ftrace-direct-modify.ko kernel module and changed to fit multi direct interface. The init function creates kthread that periodically calls modify_ftrace_direct_multi to change the trampoline address for the direct ftrace_ops. The ftrace trace_pipe then shows trace from both trampolines. Link: https://lkml.kernel.org/r/20211206182032.87248-4-jolsa@kernel.org Cc: Ingo Molnar <mingo@redhat.com> Reviewed-by:
Heiko Carstens <hca@linux.ibm.com> Tested-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org>
-
- Nov 18, 2021
-
-
Heiko Carstens authored
Add s390 architecture support for the ftrace direct multi sample. See commit 5fae941b ("ftrace/samples: Add multi direct interface test module") for further details. Link: https://lore.kernel.org/r/20211115195614.3173346-3-hca@linux.ibm.com Signed-off-by:
Heiko Carstens <hca@linux.ibm.com>
-
Heiko Carstens authored
Currently it is not possible to build the ftrace direct multi example anymore due to broken config dependencies. Fix this by adding SAMPLE_FTRACE_DIRECT_MULTI config option. This broke when merging s390-5.16-1 due to an incorrect merge conflict resolution proposed by me. Also rename SAMPLE_FTRACE_MULTI_DIRECT to SAMPLE_FTRACE_DIRECT_MULTI so it matches the module name. Fixes: 0b707e57 ("Merge tag 's390-5.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux" ) Acked-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Link: https://lore.kernel.org/r/20211115195614.3173346-2-hca@linux.ibm.com Signed-off-by:
Heiko Carstens <hca@linux.ibm.com>
-
- Nov 16, 2021
-
-
Alexander Lobakin authored
Since recent Kbuild updates we no longer include files from compiler directories. However, samples/bpf/hbm_kern.h hasn't been tuned for this (LLVM 13): CLANG-bpf samples/bpf/hbm_out_kern.o In file included from samples/bpf/hbm_out_kern.c:55: samples/bpf/hbm_kern.h:12:10: fatal error: 'stddef.h' file not found ^~~~~~~~~~ 1 error generated. CLANG-bpf samples/bpf/hbm_edt_kern.o In file included from samples/bpf/hbm_edt_kern.c:53: samples/bpf/hbm_kern.h:12:10: fatal error: 'stddef.h' file not found ^~~~~~~~~~ 1 error generated. It is enough to just drop both stdbool.h and stddef.h from includes to fix those. Fixes: 04e85bbf ("isystem: delete global -isystem compile option") Signed-off-by:
Alexander Lobakin <alexandr.lobakin@intel.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Reviewed-by:
Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://lore.kernel.org/bpf/20211115130741.3584-1-alexandr.lobakin@intel.com Signed-off-by:
Alexei Starovoitov <ast@kernel.org>
-
- Nov 13, 2021
-
-
Kumar Kartikeya Dwivedi authored
Commit b599015f ("samples/bpf: Fix application of sizeof to pointer") tried to fix a bug where sizeof was incorrectly applied to a pointer instead of the array string was being copied to, to find the destination buffer size, but ended up using strlen, which is still incorrect. However, on closer look ifname_buf has no other use, hence directly use optarg. Fixes: b599015f ("samples/bpf: Fix application of sizeof to pointer") Fixes: e531a220 ("samples: bpf: Convert xdp_redirect_cpu to XDP samples helper") Signed-off-by:
Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Reviewed-by:
Alexander Lobakin <alexandr.lobakin@intel.com> Tested-by:
Alexander Lobakin <alexandr.lobakin@intel.com> Link: https://lore.kernel.org/bpf/20211112020301.528357-1-memxor@gmail.com Signed-off-by:
Alexei Starovoitov <ast@kernel.org>
-
Alexander Lobakin authored
sample_summary_print() uses accumulated period to calculate and display per-sec averages. This period gets incremented by sampling interval each time a new sample is formed, and thus equals to the number of samples collected multiplied by this interval. However, the totals are being calculated differently, they receive current sample statistics already divided by the interval gotten as a difference between sample timestamps for better precision -- in other words, they are being incremented by the per-sec values each sample. This leads to the excessive division of summary per-secs when interval != 1 sec. It is obvious pps couldn't become two times lower just from picking a different sampling interval value: $ samples/bpf/xdp_redirect_cpu -p xdp_prognum_n1_inverse_qnum -c all -s -d 6 -i 1 < snip > Packets received : 2,197,230,321 Average packets/s : 22,887,816 Packets redirected : 2,197,230,472 Average redir/s : 22,887,817 $ samples/bpf/xdp_redirect_cpu -p xdp_prognum_n1_inverse_qnum -c all -s -d 6 -i 2 < snip > Packets received : 159,566,498 Average packets/s : 11,397,607 Packets redirected : 159,566,995 Average redir/s : 11,397,642 This can be easily fixed by treating the divisor not as a period, but rather as a total number of samples, and thus incrementing it by 1 instead of interval. As a nice side effect, we can now remove so-named argument from a couple of functions. Let us also create an "alias" for sample_output::rx_cnt::pps named 'num' using a union since this field is used to store this number (period previously) as well, and the resulting counter-intuitive code might've been a reason for this bug. Fixes: 156f886c ("samples: bpf: Add basic infrastructure for XDP samples") Signed-off-by:
Alexander Lobakin <alexandr.lobakin@intel.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Reviewed-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Reviewed-by:
Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/bpf/20211111215703.690-1-alexandr.lobakin@intel.com Signed-off-by:
Alexei Starovoitov <ast@kernel.org>
-
- Nov 07, 2021
-
-
Linus Torvalds authored
Commit 54510930 ("samples: Add fs error monitoring example") added a new sample program, but didn't teach git to ignore the new generated files, causing unnecessary noise from 'git status' after a full build. Add the 'fs-monitor' sample executable to the .gitignore for this subdirectory to silence it all again. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Nov 02, 2021
-
-
Jiri Olsa authored
There's compilation fail reported kernel test robot for W=1 build: >> samples/ftrace/ftrace-direct-multi.c:8:6: warning: no previous prototype for function 'my_direct_func' [-Wmissing-prototypes] void my_direct_func(unsigned long ip) The inlined assembly is used outside function, so we can't make my_direct_func static and pass it as asm input argument. However my_tramp is already extern so I think there's no problem keeping my_direct_func extern as well and just add its prototype. Link: https://lkml.kernel.org/r/20211101153907.377668-1-jolsa@kernel.org Reported-by:
kernel test robot <lkp@intel.com> Fixes: 5fae941b ("ftrace/samples: Add multi direct interface test module") Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org>
-
- Nov 01, 2021
-
-
'sys/types.h' included in 'samples/fanotify/fs-monitor.c' is duplicated.It is also included on 15 line. Link: https://lore.kernel.org/r/20211101075152.35780-1-zhang.mingyu@zte.com.cn Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Zhang Mingyu <zhang.mingyu@zte.com.cn> Signed-off-by:
Jan Kara <jack@suse.cz>
-
Jan Kara authored
The fsnotify sample code generates the following warning on powerpc: samples/fanotify/fs-monitor.c: In function 'handle_notifications': samples/fanotify/fs-monitor.c:68:36: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long unsigned int'} [-Wformat=] 68 | printf("unexpected FAN MARK: %llx\n", event->mask); | ~~~^ ~~~~~~~~~~~ | | | | | __u64 {aka long unsigned int} | long long unsigned int | %lx Fix the problem by explicitely typing the argument to proper type. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Jan Kara <jack@suse.cz>
-
Prevent build errors when headers or libc are not available, such as on kernel build bots, like the below: samples/fanotify/fs-monitor.c:7:10: fatal error: errno.h: No such file or directory 7 | #include <errno.h> | ^~~~~~~~~ Link: https://lore.kernel.org/r/87fsslasgz.fsf@collabora.com Suggested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Gabriel Krisman Bertazi <krisman@collabora.com> Signed-off-by:
Jan Kara <jack@suse.cz>
-
- Oct 27, 2021
-
-
Introduce an example of a FAN_FS_ERROR fanotify user to track filesystem errors. Link: https://lore.kernel.org/r/20211025192746.66445-31-krisman@collabora.com Reviewed-by:
Amir Goldstein <amir73il@gmail.com> Reviewed-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Gabriel Krisman Bertazi <krisman@collabora.com> Signed-off-by:
Jan Kara <jack@suse.cz>
-
- Oct 26, 2021
-
-
Tiezhu Yang authored
Use the actual return value instead of always -1 if register_kretprobe() failed. E.g. without this patch: # insmod samples/kprobes/kretprobe_example.ko func=no_such_func insmod: ERROR: could not insert module samples/kprobes/kretprobe_example.ko: Operation not permitted With this patch: # insmod samples/kprobes/kretprobe_example.ko func=no_such_func insmod: ERROR: could not insert module samples/kprobes/kretprobe_example.ko: Unknown symbol in module Link: https://lkml.kernel.org/r/1635213091-24387-2-git-send-email-yangtiezhu@loongson.cn Fixes: 804defea ("Kprobes: move kprobe examples to samples/") Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Acked-by:
Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org>
-
Ilya Leoshkevich authored
Use the compiler-defined __BYTE_ORDER__ instead of the libc-defined __BYTE_ORDER for consistency. Signed-off-by:
Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211026010831.748682-5-iii@linux.ibm.com
-
- Oct 25, 2021
-
-
Greg Kroah-Hartman authored
In order to better track where in the kernel the dma-buf code is used, put the symbols in the namespace DMA_BUF and modify all users of the symbols to properly import the namespace to not break the build at the same time. Now the output of modinfo shows the use of these symbols, making it easier to watch for users over time: $ modinfo drivers/misc/fastrpc.ko | grep import import_ns: DMA_BUF Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: dri-devel@lists.freedesktop.org Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Christian König <christian.koenig@amd.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Sumit Semwal <sumit.semwal@linaro.org> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20211010124628.17691-1-gregkh@linuxfoundation.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Oct 21, 2021
-
-
Pu Lehui authored
When compiling bpf samples, the following warning appears: 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 Same problem was mentioned in commit 2f092126 ("selftests/bpf: suppress readelf stderr when probing for BTF support"), let's use readelf that supports btf. Signed-off-by:
Pu Lehui <pulehui@huawei.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20211021123913.48833-1-pulehui@huawei.com
-
Jiri Olsa authored
Adding simple module that uses multi direct interface: register_ftrace_direct_multi unregister_ftrace_direct_multi The init function registers trampoline for 2 functions, and exit function unregisters them. Link: https://lkml.kernel.org/r/20211008091336.33616-9-jolsa@kernel.org Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org>
-
- Oct 20, 2021
-
-
David Yang authored
The coccinelle check report: "./samples/bpf/xdp_redirect_cpu_user.c:397:32-38: ERROR: application of sizeof to pointer" Using the "strlen" to fix it. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
David Yang <davidcomponentone@gmail.com> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211012111649.983253-1-davidcomponentone@gmail.com
-
- Oct 19, 2021
-
-
Heiko Carstens authored
Add s390 support for ftrace direct call samples, which also enables ftrace direct call selftests within ftrace selftests. Acked-by:
Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by:
Sven Schnelle <svens@linux.ibm.com> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Acked-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Link: https://lore.kernel.org/r/20211012133802.2460757-5-hca@linux.ibm.com Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Heiko Carstens authored
Add HAVE_SAMPLE_FTRACE_DIRECT config option which can be selected by architectures which have support for ftrace direct call samples. Acked-by:
Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by:
Sven Schnelle <svens@linux.ibm.com> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Acked-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Link: https://lore.kernel.org/r/20211012133802.2460757-4-hca@linux.ibm.com Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
- Oct 13, 2021
-
-
Sebastian Andrzej Siewior authored
The variables names read_lock and write_lock can clash with functions used for read/writer locks. Rename read_lock to read_access and write_lock to write_access to avoid a name collision. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lkml.kernel.org/r/20210806152551.qio7c3ho6pexezup@linutronix.de Link: https://lore.kernel.org/r/20210923172918.o22iwgvn3w7ilh44@linutronix.de Acked-by:
Stefani Seibold <stefani@seibold.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Oct 08, 2021
-
-
Quentin Monnet authored
In samples/bpf/Makefile, libbpf has a FORCE dependency that force it to be rebuilt. I read this as a way to keep the library up-to-date, given that we do not have, in samples/bpf, a list of the source files for libbpf itself. However, a better approach would be to use the "$(wildcard ...)" function from make, and to have libbpf depend on all the .c and .h files in its directory. This is what samples/bpf/Makefile does for bpftool, and also what the BPF selftests' Makefile does for libbpf. Let's update the Makefile to avoid rebuilding libbpf all the time (and bpftool on top of it). Signed-off-by:
Quentin Monnet <quentin@isovalent.com> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211007194438.34443-11-quentin@isovalent.com
-
Quentin Monnet authored
API headers from libbpf should not be accessed directly from the source directory. Instead, they should be exported with "make install_headers". Make sure that samples/bpf/Makefile installs the headers properly when building. The object compiled from and exported by libbpf are now placed into a subdirectory of sample/bpf/ instead of remaining in tools/lib/bpf/. We attempt to remove this directory on "make clean". However, the "clean" target re-enters the samples/bpf/ directory from the root of the repository ("$(MAKE) -C ../../ M=$(CURDIR) clean"), in such a way that $(srctree) and $(src) are not defined, making it impossible to use $(LIBBPF_OUTPUT) and $(LIBBPF_DESTDIR) in the recipe. So we only attempt to clean $(CURDIR)/libbpf, which is the default value. Add a dependency on libbpf's headers for the $(TRACE_HELPERS). We also change the output directory for bpftool, to place the generated objects under samples/bpf/bpftool/ instead of building in bpftool's directory directly. Doing so, we make sure bpftool reuses the libbpf library previously compiled and installed. Signed-off-by:
Quentin Monnet <quentin@isovalent.com> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211007194438.34443-10-quentin@isovalent.com
-
Quentin Monnet authored
Update samples/bpf/.gitignore to ignore files generated when building the samples. Add: - vmlinux.h - the generated skeleton files (*.skel.h) - the samples/bpf/libbpf/ and .../bpftool/ directories, in preparation of a future commit which introduces a local output directory for building libbpf and bpftool. Signed-off-by:
Quentin Monnet <quentin@isovalent.com> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211007194438.34443-9-quentin@isovalent.com
-
- Oct 06, 2021
-
-
Hengqi Chen authored
Replace deprecated bpf_{map,program}__next APIs with newly added bpf_object__next_{map,program} APIs, so that no compilation warnings emit. Signed-off-by:
Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Acked-by:
Song Liu <songliubraving@fb.com> Link: https://lore.kernel.org/bpf/20211003165844.4054931-3-hengqi.chen@gmail.com
-
Quentin Monnet authored
Recent-ish versions of make do no longer consider number signs ("#") as comment symbols when they are inserted inside of a macro reference or in a function invocation. In such cases, the symbols should not be escaped. There are a few occurrences of "\#" in libbpf's and samples' Makefiles. In the former, the backslash is harmless, because grep associates no particular meaning to the escaped symbol and reads it as a regular "#". In samples' Makefile, recent versions of make will pass the backslash down to the compiler, making the probe fail all the time and resulting in the display of a warning about "make headers_install" being required, even after headers have been installed. A similar issue has been addressed at some other locations by commit 9564a8cf ("Kbuild: fix # escaping in .cmd files for future Make"). Let's address it for libbpf's and samples' Makefiles in the same fashion, by using a "$(pound)" variable (pulled from tools/scripts/Makefile.include for libbpf, or re-defined for the samples). Reference for the change in make: https://git.savannah.gnu.org/cgit/make.git/commit/?id=c6966b323811c37acedff05b57 Fixes: 2f383041 ("libbpf: Make libbpf_version.h non-auto-generated") Fixes: 07c3bbdb ("samples: bpf: print a warning about headers_install") Signed-off-by:
Quentin Monnet <quentin@isovalent.com> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211006111049.20708-1-quentin@isovalent.com
-
- Sep 30, 2021
-
-
Christoph Hellwig authored
Reuse the logic in vfio_noiommu_group_alloc to allocate a fake single-device iommu group for mediated devices by factoring out a common function, and replacing the noiommu boolean field in struct vfio_group with an enum to distinguish the three different kinds of groups. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20210924155705.4258-8-hch@lst.de Signed-off-by:
Alex Williamson <alex.williamson@redhat.com>
-
- Sep 29, 2021
-
-
Luca Boccassi authored
libbpf and bpftool have been dual-licensed to facilitate inclusion in software that is not compatible with GPL2-only (ie: Apache2), but the samples are still GPL2-only. Given these files are samples, they get naturally copied around. For example, it is the case for samples/bpf/bpf_insn.h which was copied into the systemd tree: https://github.com/systemd/systemd/blob/main/src/shared/linux/bpf_insn.h Some more context on systemd's needs specifically: Most of systemd is (L)GPL2-or-later, which means there is no perceived incompatibility with Apache2 software and can thus be linked with OpenSSL 3.0. But given this GPL2-only header is included this is currently not possible. Dual-licensing this header solves this problem for us as we are scoping a move to OpenSSL 3.0, see: https://lists.freedesktop.org/archives/systemd-devel/2021-September/046882.html Dual-license this header as GPL-2.0-only OR BSD-2-Clause to follow the same licensing used by libbpf and bpftool: 1bc38b8f ("libbpf: relicense libbpf as LGPL-2.1 OR BSD-2-Clause") 907b2236 ("tools: bpftool: dual license all files") Signed-off-by:
Luca Boccassi <bluca@debian.org> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Simon Horman <simon.horman@corigine.com> Acked-by:
Daniel Mack <daniel@zonque.org> Acked-by:
Josef Bacik <josef@toxicpanda.com> Acked-by:
Joe Stringer <joe@ovn.org> Acked-by:
Chenbo Feng <fengc@google.com> Acked-by:
Björn Töpel <bjorn@kernel.org> Acked-by:
Magnus Karlsson <magnus.karlsson@intel.com> Acked-by:
Brendan Jackman <jackmanb@google.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20210923000540.47344-1-luca.boccassi@gmail.com
-
Kumar Kartikeya Dwivedi authored
Generate vmlinux.h only from the in-tree vmlinux, and remove enum declarations that would cause a build failure in case of version mismatches. There are now two options when building the samples: 1. Compile the kernel to use in-tree vmlinux for vmlinux.h 2. Override VMLINUX_BTF for samples using something like this: make VMLINUX_BTF=/sys/kernel/btf/vmlinux -C samples/bpf This change was tested with relative builds, e.g. cases like: * make O=build -C samples/bpf * make KBUILD_OUTPUT=build -C samples/bpf * make -C samples/bpf * cd samples/bpf && make When a suitable VMLINUX_BTF is not found, the following message is printed: /home/kkd/src/linux/samples/bpf/Makefile:333: *** Cannot find a vmlinux for VMLINUX_BTF at any of " ./vmlinux", build the kernel or set VMLINUX_BTF variable. Stop. Fixes: 384b6b3b (samples: bpf: Add vmlinux.h generation support) Signed-off-by:
Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Acked-by:
Toke Høiland-Jørgensen <toke@redhat.com> Link: https://lore.kernel.org/bpf/20210928054608.1799021-1-memxor@gmail.com
-
- Sep 21, 2021
-
-
Gokul Sivakumar authored
The ARP table that is dumped when the xdp_router_ipv4 process is launched has the IP address & MAC address in non-readable network byte order format, also the alignment is off when printing the table. Address HwAddress 160000e0 1600005e0001 ff96a8c0 ffffffffffff faffffef faff7f5e0001 196a8c0 9607871293ea fb0000e0 fb00005e0001 0 0 196a8c0 9607871293ea ffff11ac ffffffffffff faffffef faff7f5e0001 fb0000e0 fb00005e0001 160000e0 1600005e0001 160000e0 1600005e0001 faffffef faff7f5e0001 fb0000e0 fb00005e0001 40011ac 40011ac4202 Fix this by converting the "Address" field from network byte order Hex into dotted decimal notation IPv4 format and "HwAddress" field from network byte order Hex into Colon separated Hex format. Also fix the aligntment of the fields in the ARP table. Address HwAddress 224.0.0.22 01:00:5e:00:00:16 192.168.150.255 ff:ff:ff:ff:ff:ff 239.255.255.250 01:00:5e:7f:ff:fa 192.168.150.1 ea:93:12:87:07:96 224.0.0.251 01:00:5e:00:00:fb 0.0.0.0 00:00:00:00:00:00 192.168.150.1 ea:93:12:87:07:96 172.17.255.255 ff:ff:ff:ff:ff:ff 239.255.255.250 01:00:5e:7f:ff:fa 224.0.0.251 01:00:5e:00:00:fb 224.0.0.22 01:00:5e:00:00:16 224.0.0.22 01:00:5e:00:00:16 239.255.255.250 01:00:5e:7f:ff:fa 224.0.0.251 01:00:5e:00:00:fb 172.17.0.4 02:42:ac:11:00:04 Signed-off-by:
Gokul Sivakumar <gokulkumar792@gmail.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20210919080305.173588-2-gokulkumar792@gmail.com
-
Gokul Sivakumar authored
The route table that is dumped when the xdp_router_ipv4 process is launched has the "Gateway" field in non-readable network byte order format, also the alignment is off when printing the table. Destination Gateway Genmask Metric Iface 0.0.0.0 196a8c0 0 0 enp7s0 0.0.0.0 196a8c0 0 0 wlp6s0 169.254.0.0 196a8c0 16 0 enp7s0 172.17.0.0 0 16 0 docker0 192.168.150.0 0 24 0 enp7s0 192.168.150.0 0 24 0 wlp6s0 Fix this by converting the "Gateway" field from network byte order Hex into dotted decimal notation IPv4 format and "Genmask" from CIDR notation into dotted decimal notation IPv4 format. Also fix the aligntment of the fields in the route table. Destination Gateway Genmask Metric Iface 0.0.0.0 192.168.150.1 0.0.0.0 0 enp7s0 0.0.0.0 192.168.150.1 0.0.0.0 0 wlp6s0 169.254.0.0 192.168.150.1 255.255.0.0 0 enp7s0 172.17.0.0 0.0.0.0 255.255.0.0 0 docker0 192.168.150.0 0.0.0.0 255.255.255.0 0 enp7s0 192.168.150.0 0.0.0.0 255.255.255.0 0 wlp6s0 Signed-off-by:
Gokul Sivakumar <gokulkumar792@gmail.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20210919080305.173588-1-gokulkumar792@gmail.com
-
- Sep 14, 2021
-
-
Andra Paraschiv authored
Remove blank lines that are not necessary, fixing the checkpatch script reports. While at it, add a blank line after the switch default block, similar to the other parts of the codebase. Reviewed-by:
George-Aurelian Popescu <popegeo@amazon.com> Signed-off-by:
Andra Paraschiv <andraprs@amazon.com> Link: https://lore.kernel.org/r/20210827154930.40608-8-andraprs@amazon.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Andra Paraschiv authored
Fix the typos in the words spelling as per the checkpatch script reports. Reviewed-by:
George-Aurelian Popescu <popegeo@amazon.com> Signed-off-by:
Andra Paraschiv <andraprs@amazon.com> Link: https://lore.kernel.org/r/20210827154930.40608-7-andraprs@amazon.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Aug 26, 2021
-
-
Kumar Kartikeya Dwivedi authored
While at it, also improve help output when CPU number is greater than possible. Fixes: e531a220 ("samples: bpf: Convert xdp_redirect_cpu to XDP samples helper") Signed-off-by:
Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20210826120910.454081-1-memxor@gmail.com
-
- Aug 25, 2021
-
-
Juhee Kang authored
All pktgen samples can send indefinitely num messages per thread by setting the count option to 0(-n 0). If running sample with setting count 0 and press Ctrl-C to stop this program, the program prints the result of the execution so far. Currently, the samples besides sample{3...5} don't work properly. Because Ctrl-C stops the script, not just pktgen. This is results of samples: # DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample04_many_flows.sh -n 0 Running... ctrl^C to stop ^CDevice: eth0@0 Result: OK: 569657(c569538+d118) usec, 84650 (60byte,0frags) 148597pps 71Mb/sec (71326560bps) errors: 0 # DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample01_simple.sh -n 0 Running... ctrl^C to stop ^C In order to solve this, this commit adds trap SIGINT. Also, this commit changes control_c function to print_result to maintain consistency with other samples. Signed-off-by:
Juhee Kang <claudiajkang@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Juhee Kang authored
Currently, most pktgen samples print the execution result when the program is terminated normally. However, sample03 doesn't work appropriately. This is results of samples: # DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample04_many_flows.sh -n 1 Running... ctrl^C to stop Device: eth0@0 Result: OK: 19(c5+d13) usec, 1 (60byte,0frags) 51762pps 24Mb/sec (24845760bps) errors: 0 # DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample03_burst_single_flow.sh -n 1 Running... ctrl^C to stop The reason why it doesn't print the execution result when the program is terminated usually is that sample03 doesn't call the function which prints the result, unlike other samples. So, this commit solves this issue by calling the function before termination. Also, this commit changes control_c function to print_result to maintain consistency with other samples. Signed-off-by:
Juhee Kang <claudiajkang@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- Aug 24, 2021
-
-
Kumar Kartikeya Dwivedi authored
Use the libbpf skeleton facility and other utilities provided by XDP samples helper. Also adapt to change of type of mac address map, so that no resizing is required. Add a new flag for sample mask that skips priting the from_device->to_device heading for each line, as xdp_redirect_map_multi may have two devices but the flow of data may be bidirectional, so the output would be confusing. Signed-off-by:
Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20210821002010.845777-23-memxor@gmail.com
-
Kumar Kartikeya Dwivedi authored
One of the notable changes is using a BPF_MAP_TYPE_HASH instead of array map to store mac addresses of devices, as the resizing behavior was based on max_ifindex, which unecessarily maximized the capacity of map beyond what was needed. Signed-off-by:
Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20210821002010.845777-22-memxor@gmail.com
-
Kumar Kartikeya Dwivedi authored
Use the libbpf skeleton facility and other utilities provided by XDP samples helper. Since get_mac_addr is already provided by XDP samples helper, we drop it. Also convert to XDP samples helper similar to prior samples to minimize duplication of code. Signed-off-by:
Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20210821002010.845777-21-memxor@gmail.com
-