- 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:
-
- 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:
-
- Nov 01, 2021
-
-
Zhang Mingyu authored
'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:
-
Gabriel Krisman Bertazi authored
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:
Gabriel Krisman Bertazi <krisman@collabora.com> Signed-off-by:
-
- Oct 27, 2021
-
-
Gabriel Krisman Bertazi authored
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:
-
- 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:
-
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:
-
- 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:
David Yang <davidcomponentone@gmail.com> Signed-off-by:
-
- 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:
Sven Schnelle <svens@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:
-
- 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:
-
- 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:
-
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 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:
-
- 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:
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:
-
- 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:
-
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:
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:
-
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:
-
- 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:
-
Andra Paraschiv authored
Fix the typos in the words spelling as per the checkpatch script reports. Reviewed-by:
-
- 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:
-
- 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:
-
- 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 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 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 authored
Also update it to use consistent SEC("xdp") and SEC("xdp_devmap") naming, and use global variable instead of BPF map for copying the mac address. Signed-off-by: -
Kumar Kartikeya Dwivedi authored
Use the libbpf skeleton facility and other utilities provided by XDP samples helper. Similar to xdp_monitor, xdp_redirect_cpu was quite featureful except a few minor omissions (e.g. redirect errno reporting). All of these have been moved to XDP samples helper, hence drop the unneeded code and convert to usage of helpers provided by it. One of the important changes here is dropping of mprog-disable option, as we make that the default. Also, we support built-in programs for some common actions on the packet when it reaches kthread (pass, drop, redirect to device). If the user still needs to install a custom program, they can still supply a BPF object, however the program should be suitably tagged with SEC("xdp_cpumap") annotation so that the expected attach type is correct when updating our cpumap map element. Signed-off-by: -
Kumar Kartikeya Dwivedi authored
Similar to xdp_monitor_kern, a lot of these BPF programs have been reimplemented properly consolidating missing features from other XDP samples. Hence, drop the unneeded code and rename to .bpf.c suffix. Signed-off-by:
-
Kumar Kartikeya Dwivedi authored
Use the libbpf skeleton facility and other utilities provided by XDP samples helper. One important note: The XDP samples helper handles ownership of installed XDP programs on devices, including responding to SIGINT and SIGTERM, so drop the code here and use the helpers we provide going forward for all xdp_redirect* conversions. Signed-off-by:
-
Kumar Kartikeya Dwivedi authored
We moved swap_src_dst_mac to xdp_sample.bpf.h to be shared with other potential users, so drop it while moving code to the new file. Also, consistently use SEC("xdp") naming instead. Signed-off-by:
-
