February 2025 - Linux-kselftest-mirror

Re: Re: Re: Re: Re: [PATCH 2/2] libbpf: BPF programs dynamic loading and attaching

by Slava Imameev

> > > On Mon, 2025-02-10 at 16:06 -0800, Andrii Nakryiko wrote: > > > > Tracking associated maps for a program is not necessary. As long as > > > > the last BPF program using the BPF map is unloaded, the kernel will > > > > automatically free not-anymore-referenced BPF map. Note that > > > > bpf_object itself will keep FDs for BPF maps, so you'd need to make > > > > sure to do bpf_object__close() to release those references. > > > > > > > > But if you are going to ask to re-create BPF maps next time BPF > > > > program is loaded... Well, I'll say you are asking for a bit too > > > > > much, > > > > tbh. If you want to be *that* sophisticated, it shouldn't be too > > > > hard > > > > for you to get all this information from BPF program's > > > > instructions. > > > > > > > > We really are that sophisticated (see below for more details). We could > > scan program instructions, but we'd then tie our logic to BPF > > implementation details and duplicate logic already present in libbpf > > (https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v6.13.2/source… <https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v6.13.2/source…>*L6087__;Iw!!BmdzS3_lV9HdKG8!384hiRcpmYOjMU3kT-1m4GxWp5XxwHj9ICrDtIUKCmCbxLVAxemc6UN64cE3Mktu_z4f2JheoKm6RBYQdc-MiPbyexk6-Rn48A$ > > ). Obviously this *can* be done but it's not at all ideal from an > > application perspective. > > > > > I agree it's not ideal, but it's also not some complicated and > bound-to-be-changed logic. What you point out in libbpf source code is > a bit different thing, reality is much simpler. Only so-called ldimm64 > instruction (BPF_LD | BPF_IMM | BPF_DW opcode) can be referencing map > FD, so analysing this is borderline trivial. And this is part of BPF > ISA, so not going to change. Our approach is to associate an array of maps as a property with each BPF program, this property is initialised at the relocation stage. So, we do not need to parse BPF program instructions. Instead, we rely on recorded relocations. I think this is a more robust and clean solution with advantage of all code in the same place and being at the higher level of abstraction with a relocation table. The mainline libbpf keeps array of maps for a bpf_object, we extended this by adding an array of maps associated with each bpf_program. For example, a code excerpt, from our development branch, which associates a map with bpf_program at relocation phase: insn[0].src_reg = BPF_PSEUDO_MAP_FD; insn[0].imm = map->fd; err = bpf_program__add_map(prog, map); > > > > > > > > > > bpf_object is the unit of coherence in libbpf, so I don't see us > > > > refcounting maps between bpf_objects. Kernel is doing refcounting > > > > based on FDs, so see if you can use that. > > > > > > > > I can understand that. That said, I think if there's no logic across > > objects, and bpf_object access is not thread-safe, it puts us into a > > tough situation: > > - Complex refcounting, code scanning, etc to keep consistency when > > manipulating maps used by multiple programs. > > - Parallel loading not being well-balanced, if we split programs across > > objects. > > > > We could alternatively write our own custom loader, but then we’d have > > to duplicate much of the useful logic that libbpf already implements: > > skeleton generation, map/program association, embedding programs into > > ELFs, loading logic and kernel probing, etc. We’d like some way to > > handle dynamic/parallel loading without having to replicate all the > > advantages libbpf grants us. > > > > > Yeah, I can understand that as well, but bpf_object's single-threaded > design and the fact that bpf_object__load is kind of the final step > where programs are loaded (or not) is pretty backed in. I don't see > bpf_object becoming multi-threaded. We understood this, but the current bpf_object design allowed us to use it in a multithreaded environment with minor modification for bpf_program load. We understand that the design choice of libbpf being single threaded is unlikely to be reconsidered. > > > > > > > > > > bpf_object is the unit of coherence in libbpf, so I don't see us > > > > refcounting maps between bpf_objects. Kernel is doing refcounting > > > > based on FDs, so see if you can use that. > > > > > > > > I can understand that. That said, I think if there's no logic across > > objects, and bpf_object access is not thread-safe, it puts us into a > > tough situation: > > - Complex refcounting, code scanning, etc to keep consistency when > > manipulating maps used by multiple programs. > > - Parallel loading not being well-balanced, if we split programs across > > objects. > > > > We could alternatively write our own custom loader, but then we’d have > > to duplicate much of the useful logic that libbpf already implements: > > skeleton generation, map/program association, embedding programs into > > ELFs, loading logic and kernel probing, etc. We’d like some way to > > handle dynamic/parallel loading without having to replicate all the > > advantages libbpf grants us. > > > > > Yeah, I can understand that as well, but bpf_object's single-threaded > design and the fact that bpf_object__load is kind of the final step > where programs are loaded (or not) is pretty backed in. I don't see > bpf_object becoming multi-threaded. The dynamic program > loading/unloading/loading again is something that I can't yet justify, > tbh. > > > So the best I can propose you is to use libbpf's skeleton and > bpf_object concept for, effectively, ELF handling, relocations, all > the preparations up to loading BPF programs. And after that you can > take over loading and handling program lifetime outside of bpf_object. > > > Dynamic map creation after bpf_object__load() I think is completely > outside of the scope and you'll have to solve this problem for > yourself. I would point out, though, that internally libbpf already > switched to sort-of pre-creating stable FDs for maps before they are > actually created in the kernel. So it's conceivable that we can have > more granularity in bpf_object preparation. I.e., first step would be > to parse ELF and handle relocations, prepare everything. After that we > can have a step to create maps, and then another one to create > programs. Usually people would do all that, but you can stop right > before maps creation or before program creation, whatever fits your > use case better. > > > The key is that program instructions will be final and won't need > adjustments regardless of maps actually being created or not. FDs, as > I mentioned, are stable regardless. We used this in our design, so we did not need to scan BPF program instructions to fix map's fds referenced by instructions from a dynamically loaded bpf_program with dynamically created maps. > > > > The use case here is that our security monitoring agent leverages eBPF > > as its foundational technology to gather telemetry from the kernel. As > > part of that, we hook many different kernel subsystems (process, > > memory, filesystem, network, etc), tying them together and tracking > > with maps. So we legitimately have a very large number of programs all > > doing different work. For products of this scale, it increases security > > and performance to load this set of programs and their maps in an > > optimized, parallel fashion and subsequently change the loaded set of > > programs and maps dynamically without disturbing the rest of the > > application. > > > Yes, makes sense. You'll need to decide for yourself if it's actually > more meaningful to split those 200 programs into independent > bpf_objects by features, and be rigorous about sharing state (maps) > through bpf_map__reuse_fd(), which would allow to parallelize loading > within confines of existing libbpf APIs. Or you can be a bit more > low-level with program loading outside of bpf_object API, as I > described above. Yes, this can be one of the ways to share bpf maps across multiple bpf_objects and use existing libbpf for parallel bps programs loading, if we want to keep a full libbpf compatibility, but at a cost of complicating design, as we need to convert a single bpf_object model to multiple bpf_objects with a new layer that manages these bpf_objects. In our case, as a bpf_program can map to multiple features, which can be modified independently, and to achieve an even load balancing across multiple threads, it would be probably one bpf_program for a bpf_object.

8 months

1
0
0 0

[RESEND PATCH v2] wireguard: selftests: Cleanup CONFIG_UBSAN_SANITIZE_ALL

by WangYuli

Commit 918327e9b7ff ("ubsan: Remove CONFIG_UBSAN_SANITIZE_ALL") removed the CONFIG_UBSAN_SANITIZE_ALL configuration option. Eliminate invalid configurations to improve code readability. Link: https://lore.kernel.org/all/20250123105743.GO395043@kernel.org/ Reviewed-by: Simon Horman <horms(a)kernel.org> Signed-off-by: WangYuli <wangyuli(a)uniontech.com> --- Changelog: *v1->v2: Add Simon Horman's "Reviewed-by" tag. Signed-off-by: WangYuli <wangyuli(a)uniontech.com> --- tools/testing/selftests/wireguard/qemu/debug.config | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/testing/selftests/wireguard/qemu/debug.config b/tools/testing/selftests/wireguard/qemu/debug.config index 139fd9aa8b12..828f14300d0a 100644 --- a/tools/testing/selftests/wireguard/qemu/debug.config +++ b/tools/testing/selftests/wireguard/qemu/debug.config @@ -22,7 +22,6 @@ CONFIG_HAVE_ARCH_KASAN=y CONFIG_KASAN=y CONFIG_KASAN_INLINE=y CONFIG_UBSAN=y -CONFIG_UBSAN_SANITIZE_ALL=y CONFIG_DEBUG_KMEMLEAK=y CONFIG_DEBUG_STACK_USAGE=y CONFIG_DEBUG_SHIRQ=y -- 2.47.2

8 months

2
1
0 0

[PATCH 00/16] selftests: vDSO: parse_vdso: Make compatible with nolibc

by Thomas Weißschuh

For testing the functionality of the vDSO, it is necessary to build userspace programs for multiple different architectures. It is additional work to acquire matching userspace cross-compilers with full C libraries and then building root images out of those. The kernel tree already contains nolibc, a small, header-only C library. By using it, it is possible to build userspace programs without any additional dependencies. For example the kernel.org crosstools or multi-target clang can be used to build test programs for a multitude of architectures. While nolibc is very limited, it is enough for many selftests. With some minor adjustments it is possible to make parse_vdso.c compatible with nolibc. As an example, vdso_standalone_test_x86 is now built from the same C code as the regular vdso_test_gettimeofday, while still being completely standalone. This should probably go through the kselftest tree. Signed-off-by: Thomas Weißschuh <thomas.weissschuh(a)linutronix.de> --- Thomas Weißschuh (16): MAINTAINERS: Add vDSO selftests elf, uapi: Add definition for STN_UNDEF elf, uapi: Add definition for DT_GNU_HASH elf, uapi: Add definitions for VER_FLG_BASE and VER_FLG_WEAK elf, uapi: Add type ElfXX_Versym elf, uapi: Add types ElfXX_Verdef and ElfXX_Veraux tools/include: Add uapi/linux/elf.h selftests: Add headers target selftests: vDSO: vdso_standalone_test_x86: Use vdso_init_form_sysinfo_ehdr selftests: vDSO: parse_vdso: Drop vdso_init_from_auxv() selftests: vDSO: parse_vdso: Use UAPI headers instead of libc headers selftests: vDSO: parse_vdso: Test __SIZEOF_LONG__ instead of ULONG_MAX selftests: vDSO: parse_vdso: Make compatible with nolibc selftests: vDSO: vdso_test_gettimeofday: Clean up includes selftests: vDSO: vdso_test_gettimeofday: Make compatible with nolibc selftests: vDSO: vdso_standalone_test_x86: Switch to nolibc MAINTAINERS | 1 + include/uapi/linux/elf.h | 38 ++ tools/include/uapi/linux/elf.h | 524 +++++++++++++++++++++ tools/testing/selftests/lib.mk | 5 +- tools/testing/selftests/vDSO/Makefile | 11 +- tools/testing/selftests/vDSO/parse_vdso.c | 21 +- tools/testing/selftests/vDSO/parse_vdso.h | 1 - .../selftests/vDSO/vdso_standalone_test_x86.c | 143 +----- .../selftests/vDSO/vdso_test_gettimeofday.c | 4 +- 9 files changed, 584 insertions(+), 164 deletions(-) --- base-commit: 2014c95afecee3e76ca4a56956a936e23283f05b change-id: 20241017-parse_vdso-nolibc-e069baa7ff48 Best regards, -- Thomas Weißschuh <thomas.weissschuh(a)linutronix.de>

8 months

4
31
0 0

[PATCH v9 3/3] selftests/rseq: Add test for mm_cid compaction

by Gabriele Monaco

A task in the kernel (task_mm_cid_work) runs somewhat periodically to compact the mm_cid for each process. Add a test to validate that it runs correctly and timely. The test spawns 1 thread pinned to each CPU, then each thread, including the main one, runs in short bursts for some time. During this period, the mm_cids should be spanning all numbers between 0 and nproc. At the end of this phase, a thread with high enough mm_cid (>= nproc/2) is selected to be the new leader, all other threads terminate. After some time, the only running thread should see 0 as mm_cid, if that doesn't happen, the compaction mechanism didn't work and the test fails. The test never fails if only 1 core is available, in which case, we cannot test anything as the only available mm_cid is 0. Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Signed-off-by: Gabriele Monaco <gmonaco(a)redhat.com> --- tools/testing/selftests/rseq/.gitignore | 1 + tools/testing/selftests/rseq/Makefile | 2 +- .../selftests/rseq/mm_cid_compaction_test.c | 200 ++++++++++++++++++ 3 files changed, 202 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/rseq/mm_cid_compaction_test.c diff --git a/tools/testing/selftests/rseq/.gitignore b/tools/testing/selftests/rseq/.gitignore index 16496de5f6ce4..2c89f97e4f737 100644 --- a/tools/testing/selftests/rseq/.gitignore +++ b/tools/testing/selftests/rseq/.gitignore @@ -3,6 +3,7 @@ basic_percpu_ops_test basic_percpu_ops_mm_cid_test basic_test basic_rseq_op_test +mm_cid_compaction_test param_test param_test_benchmark param_test_compare_twice diff --git a/tools/testing/selftests/rseq/Makefile b/tools/testing/selftests/rseq/Makefile index 5a3432fceb586..ce1b38f46a355 100644 --- a/tools/testing/selftests/rseq/Makefile +++ b/tools/testing/selftests/rseq/Makefile @@ -16,7 +16,7 @@ OVERRIDE_TARGETS = 1 TEST_GEN_PROGS = basic_test basic_percpu_ops_test basic_percpu_ops_mm_cid_test param_test \ param_test_benchmark param_test_compare_twice param_test_mm_cid \ - param_test_mm_cid_benchmark param_test_mm_cid_compare_twice + param_test_mm_cid_benchmark param_test_mm_cid_compare_twice mm_cid_compaction_test TEST_GEN_PROGS_EXTENDED = librseq.so diff --git a/tools/testing/selftests/rseq/mm_cid_compaction_test.c b/tools/testing/selftests/rseq/mm_cid_compaction_test.c new file mode 100644 index 0000000000000..7ddde3b657dd6 --- /dev/null +++ b/tools/testing/selftests/rseq/mm_cid_compaction_test.c @@ -0,0 +1,200 @@ +// SPDX-License-Identifier: LGPL-2.1 +#define _GNU_SOURCE +#include <assert.h> +#include <pthread.h> +#include <sched.h> +#include <stdint.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <stddef.h> + +#include "../kselftest.h" +#include "rseq.h" + +#define VERBOSE 0 +#define printf_verbose(fmt, ...) \ + do { \ + if (VERBOSE) \ + printf(fmt, ##__VA_ARGS__); \ + } while (0) + +/* 0.5 s */ +#define RUNNER_PERIOD 500000 +/* Number of runs before we terminate or get the token */ +#define THREAD_RUNS 5 + +/* + * Number of times we check that the mm_cid were compacted. + * Checks are repeated every RUNNER_PERIOD. + */ +#define MM_CID_COMPACT_TIMEOUT 10 + +struct thread_args { + int cpu; + int num_cpus; + pthread_mutex_t *token; + pthread_barrier_t *barrier; + pthread_t *tinfo; + struct thread_args *args_head; +}; + +static void __noreturn *thread_runner(void *arg) +{ + struct thread_args *args = arg; + int i, ret, curr_mm_cid; + cpu_set_t cpumask; + + CPU_ZERO(&cpumask); + CPU_SET(args->cpu, &cpumask); + ret = pthread_setaffinity_np(pthread_self(), sizeof(cpumask), &cpumask); + if (ret) { + errno = ret; + perror("Error: failed to set affinity"); + abort(); + } + pthread_barrier_wait(args->barrier); + + for (i = 0; i < THREAD_RUNS; i++) + usleep(RUNNER_PERIOD); + curr_mm_cid = rseq_current_mm_cid(); + /* + * We select one thread with high enough mm_cid to be the new leader. + * All other threads (including the main thread) will terminate. + * After some time, the mm_cid of the only remaining thread should + * converge to 0, if not, the test fails. + */ + if (curr_mm_cid >= args->num_cpus / 2 && + !pthread_mutex_trylock(args->token)) { + printf_verbose( + "cpu%d has mm_cid=%d and will be the new leader.\n", + sched_getcpu(), curr_mm_cid); + for (i = 0; i < args->num_cpus; i++) { + if (args->tinfo[i] == pthread_self()) + continue; + ret = pthread_join(args->tinfo[i], NULL); + if (ret) { + errno = ret; + perror("Error: failed to join thread"); + abort(); + } + } + pthread_barrier_destroy(args->barrier); + free(args->tinfo); + free(args->token); + free(args->barrier); + free(args->args_head); + + for (i = 0; i < MM_CID_COMPACT_TIMEOUT; i++) { + curr_mm_cid = rseq_current_mm_cid(); + printf_verbose("run %d: mm_cid=%d on cpu%d.\n", i, + curr_mm_cid, sched_getcpu()); + if (curr_mm_cid == 0) + exit(EXIT_SUCCESS); + usleep(RUNNER_PERIOD); + } + exit(EXIT_FAILURE); + } + printf_verbose("cpu%d has mm_cid=%d and is going to terminate.\n", + sched_getcpu(), curr_mm_cid); + pthread_exit(NULL); +} + +int test_mm_cid_compaction(void) +{ + cpu_set_t affinity; + int i, j, ret = 0, num_threads; + pthread_t *tinfo; + pthread_mutex_t *token; + pthread_barrier_t *barrier; + struct thread_args *args; + + sched_getaffinity(0, sizeof(affinity), &affinity); + num_threads = CPU_COUNT(&affinity); + tinfo = calloc(num_threads, sizeof(*tinfo)); + if (!tinfo) { + perror("Error: failed to allocate tinfo"); + return -1; + } + args = calloc(num_threads, sizeof(*args)); + if (!args) { + perror("Error: failed to allocate args"); + ret = -1; + goto out_free_tinfo; + } + token = malloc(sizeof(*token)); + if (!token) { + perror("Error: failed to allocate token"); + ret = -1; + goto out_free_args; + } + barrier = malloc(sizeof(*barrier)); + if (!barrier) { + perror("Error: failed to allocate barrier"); + ret = -1; + goto out_free_token; + } + if (num_threads == 1) { + fprintf(stderr, "Cannot test on a single cpu. " + "Skipping mm_cid_compaction test.\n"); + /* only skipping the test, this is not a failure */ + goto out_free_barrier; + } + pthread_mutex_init(token, NULL); + ret = pthread_barrier_init(barrier, NULL, num_threads); + if (ret) { + errno = ret; + perror("Error: failed to initialise barrier"); + goto out_free_barrier; + } + for (i = 0, j = 0; i < CPU_SETSIZE && j < num_threads; i++) { + if (!CPU_ISSET(i, &affinity)) + continue; + args[j].num_cpus = num_threads; + args[j].tinfo = tinfo; + args[j].token = token; + args[j].barrier = barrier; + args[j].cpu = i; + args[j].args_head = args; + if (!j) { + /* The first thread is the main one */ + tinfo[0] = pthread_self(); + ++j; + continue; + } + ret = pthread_create(&tinfo[j], NULL, thread_runner, &args[j]); + if (ret) { + errno = ret; + perror("Error: failed to create thread"); + abort(); + } + ++j; + } + printf_verbose("Started %d threads.\n", num_threads); + + /* Also main thread will terminate if it is not selected as leader */ + thread_runner(&args[0]); + + /* only reached in case of errors */ +out_free_barrier: + free(barrier); +out_free_token: + free(token); +out_free_args: + free(args); +out_free_tinfo: + free(tinfo); + + return ret; +} + +int main(int argc, char **argv) +{ + if (!rseq_mm_cid_available()) { + fprintf(stderr, "Error: rseq_mm_cid unavailable\n"); + return -1; + } + if (test_mm_cid_compaction()) + return -1; + return 0; +} -- 2.48.1

8 months

1
0
0 0

[PATCH] selftests/memory-hotplug: debugging improvement

by Leonardo Felipe Takao Hirata

Formats testing messages to improve debugging: - Inserts alignment tabs with printf for testing results - Changes messages to improve readability and understanding Signed-off-by: Leonardo Felipe Takao Hirata <leofthirata(a)gmail.com> --- .../memory-hotplug/mem-on-off-test.sh | 21 ++++++++++++------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh b/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh index 611be86eaf3d..7a2eea366c1b 100755 --- a/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh +++ b/tools/testing/selftests/memory-hotplug/mem-on-off-test.sh @@ -143,6 +143,11 @@ online_all_offline_memory() done } +print_status() +{ + printf '\t\t%-37s %12s\n' "$1" "$2" +} + error=-12 priority=0 # Run with default of ratio=2 for Kselftest run @@ -184,16 +189,16 @@ echo "Test scope: $ratio% hotplug memory" # Online all hot-pluggable memory # hotpluggable_num=`hotpluggable_offline_memory | wc -l` -echo -e "\t online all hot-pluggable memory in offline state:" +echo -e "Changing all OFFLINE hot-pluggable memory blocks to ONLINE:\n" if [ "$hotpluggable_num" -gt 0 ]; then for memory in `hotpluggable_offline_memory`; do - echo "offline->online memory$memory" + echo -e "\t\tOFFLINE -> ONLINE memory block ($memory)" if ! online_memory_expect_success $memory; then retval=1 fi done else - echo -e "\t\t SKIPPED - no hot-pluggable memory in offline state" + echo -e "\t\t SKIPPED - no hot-pluggable memory in OFFLINE state" fi # @@ -201,16 +206,16 @@ fi # hotpluggable_num=`hotpluggable_online_memory | wc -l` target=`echo "a=$hotpluggable_num*$ratio; if ( a%100 ) a/100+1 else a/100" | bc` -echo -e "\t offline $ratio% hot-pluggable memory in online state" -echo -e "\t trying to offline $target out of $hotpluggable_num memory block(s):" +echo -e "\nOFFLINE $ratio% hot-pluggable memory in ONLINE state ($target memory block(s))" +echo -e "Changing $target out of $hotpluggable_num OFFLINE memory block(s) to ONLINE:\n" for memory in `hotpluggable_online_memory`; do if [ "$target" -gt 0 ]; then - echo "online->offline memory$memory" + tmp="ONLINE -> OFFLINE memory block (${memory})" if offline_memory_expect_success $memory &>/dev/null; then target=$(($target - 1)) - echo "-> Success" + print_status "$tmp" "[SUCCESS]" else - echo "-> Failure" + print_status "$tmp" "[FAILURE]" fi fi done -- 2.43.0

8 months

1
0
0 0

[PATCH AUTOSEL 6.6 02/20] selftests/bpf: Fix invalid flag of recv()

by Sasha Levin

From: Jiayuan Chen <mrpre(a)163.com> [ Upstream commit a0c11149509aa905aeec10cf9998091443472b0b ] SOCK_NONBLOCK flag is only effective during socket creation, not during recv. Use MSG_DONTWAIT instead. Signed-off-by: Jiayuan Chen <mrpre(a)163.com> Signed-off-by: Martin KaFai Lau <martin.lau(a)kernel.org> Acked-by: Jakub Sitnicki <jakub(a)cloudflare.com> Acked-by: John Fastabend <john.fastabend(a)gmail.com> Link: https://patch.msgid.link/20250122100917.49845-5-mrpre@163.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/bpf/prog_tests/sockmap_basic.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c b/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c index dda7060e86a09..b16d765a153a9 100644 --- a/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c +++ b/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c @@ -402,8 +402,8 @@ static void test_sockmap_skb_verdict_shutdown(void) if (!ASSERT_EQ(err, 1, "epoll_wait(fd)")) goto out_close; - n = recv(c1, &b, 1, SOCK_NONBLOCK); - ASSERT_EQ(n, 0, "recv_timeout(fin)"); + n = recv(c1, &b, 1, MSG_DONTWAIT); + ASSERT_EQ(n, 0, "recv(fin)"); out_close: close(c1); close(p1); @@ -459,7 +459,7 @@ static void test_sockmap_skb_verdict_fionread(bool pass_prog) ASSERT_EQ(avail, expected, "ioctl(FIONREAD)"); /* On DROP test there will be no data to read */ if (pass_prog) { - recvd = recv_timeout(c1, &buf, sizeof(buf), SOCK_NONBLOCK, IO_TIMEOUT_SEC); + recvd = recv_timeout(c1, &buf, sizeof(buf), MSG_DONTWAIT, IO_TIMEOUT_SEC); ASSERT_EQ(recvd, sizeof(buf), "recv_timeout(c0)"); } -- 2.39.5

8 months

1
0
0 0

[PATCH AUTOSEL 6.12 02/28] selftests/bpf: Fix invalid flag of recv()

by Sasha Levin

From: Jiayuan Chen <mrpre(a)163.com> [ Upstream commit a0c11149509aa905aeec10cf9998091443472b0b ] SOCK_NONBLOCK flag is only effective during socket creation, not during recv. Use MSG_DONTWAIT instead. Signed-off-by: Jiayuan Chen <mrpre(a)163.com> Signed-off-by: Martin KaFai Lau <martin.lau(a)kernel.org> Acked-by: Jakub Sitnicki <jakub(a)cloudflare.com> Acked-by: John Fastabend <john.fastabend(a)gmail.com> Link: https://patch.msgid.link/20250122100917.49845-5-mrpre@163.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/bpf/prog_tests/sockmap_basic.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c b/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c index 82bfb266741cf..fb08c565d6aad 100644 --- a/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c +++ b/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c @@ -492,8 +492,8 @@ static void test_sockmap_skb_verdict_shutdown(void) if (!ASSERT_EQ(err, 1, "epoll_wait(fd)")) goto out_close; - n = recv(c1, &b, 1, SOCK_NONBLOCK); - ASSERT_EQ(n, 0, "recv_timeout(fin)"); + n = recv(c1, &b, 1, MSG_DONTWAIT); + ASSERT_EQ(n, 0, "recv(fin)"); out_close: close(c1); close(p1); @@ -546,7 +546,7 @@ static void test_sockmap_skb_verdict_fionread(bool pass_prog) ASSERT_EQ(avail, expected, "ioctl(FIONREAD)"); /* On DROP test there will be no data to read */ if (pass_prog) { - recvd = recv_timeout(c1, &buf, sizeof(buf), SOCK_NONBLOCK, IO_TIMEOUT_SEC); + recvd = recv_timeout(c1, &buf, sizeof(buf), MSG_DONTWAIT, IO_TIMEOUT_SEC); ASSERT_EQ(recvd, sizeof(buf), "recv_timeout(c0)"); } -- 2.39.5

8 months

1
0
0 0

[PATCH AUTOSEL 6.13 01/32] selftests/bpf: Adjust data size to have ETH_HLEN

by Sasha Levin

From: Shigeru Yoshida <syoshida(a)redhat.com> [ Upstream commit c7f2188d68c114095660a950b7e880a1e5a71c8f ] The function bpf_test_init() now returns an error if user_size (.data_size_in) is less than ETH_HLEN, causing the tests to fail. Adjust the data size to ensure it meets the requirement of ETH_HLEN. Signed-off-by: Shigeru Yoshida <syoshida(a)redhat.com> Signed-off-by: Martin KaFai Lau <martin.lau(a)kernel.org> Link: https://patch.msgid.link/20250121150643.671650-2-syoshida@redhat.com Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- .../testing/selftests/bpf/prog_tests/xdp_cpumap_attach.c | 4 ++-- .../testing/selftests/bpf/prog_tests/xdp_devmap_attach.c | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/tools/testing/selftests/bpf/prog_tests/xdp_cpumap_attach.c b/tools/testing/selftests/bpf/prog_tests/xdp_cpumap_attach.c index c7f74f068e788..df27535995af8 100644 --- a/tools/testing/selftests/bpf/prog_tests/xdp_cpumap_attach.c +++ b/tools/testing/selftests/bpf/prog_tests/xdp_cpumap_attach.c @@ -52,10 +52,10 @@ static void test_xdp_with_cpumap_helpers(void) ASSERT_EQ(info.id, val.bpf_prog.id, "Match program id to cpumap entry prog_id"); /* send a packet to trigger any potential bugs in there */ - char data[10] = {}; + char data[ETH_HLEN] = {}; DECLARE_LIBBPF_OPTS(bpf_test_run_opts, opts, .data_in = &data, - .data_size_in = 10, + .data_size_in = sizeof(data), .flags = BPF_F_TEST_XDP_LIVE_FRAMES, .repeat = 1, ); diff --git a/tools/testing/selftests/bpf/prog_tests/xdp_devmap_attach.c b/tools/testing/selftests/bpf/prog_tests/xdp_devmap_attach.c index 27ffed17d4be3..461ab18705d5c 100644 --- a/tools/testing/selftests/bpf/prog_tests/xdp_devmap_attach.c +++ b/tools/testing/selftests/bpf/prog_tests/xdp_devmap_attach.c @@ -23,7 +23,7 @@ static void test_xdp_with_devmap_helpers(void) __u32 len = sizeof(info); int err, dm_fd, dm_fd_redir, map_fd; struct nstoken *nstoken = NULL; - char data[10] = {}; + char data[ETH_HLEN] = {}; __u32 idx = 0; SYS(out_close, "ip netns add %s", TEST_NS); @@ -58,7 +58,7 @@ static void test_xdp_with_devmap_helpers(void) /* send a packet to trigger any potential bugs in there */ DECLARE_LIBBPF_OPTS(bpf_test_run_opts, opts, .data_in = &data, - .data_size_in = 10, + .data_size_in = sizeof(data), .flags = BPF_F_TEST_XDP_LIVE_FRAMES, .repeat = 1, ); @@ -158,7 +158,7 @@ static void test_xdp_with_devmap_helpers_veth(void) struct nstoken *nstoken = NULL; __u32 len = sizeof(info); int err, dm_fd, dm_fd_redir, map_fd, ifindex_dst; - char data[10] = {}; + char data[ETH_HLEN] = {}; __u32 idx = 0; SYS(out_close, "ip netns add %s", TEST_NS); @@ -208,7 +208,7 @@ static void test_xdp_with_devmap_helpers_veth(void) /* send a packet to trigger any potential bugs in there */ DECLARE_LIBBPF_OPTS(bpf_test_run_opts, opts, .data_in = &data, - .data_size_in = 10, + .data_size_in = sizeof(data), .flags = BPF_F_TEST_XDP_LIVE_FRAMES, .repeat = 1, ); -- 2.39.5

8 months

1
1
0 0

[PATCH -next] selftests/filesystems: Remove duplicate sys/types.h header

by Jiapeng Chong

./tools/testing/selftests/filesystems/utils.c: sys/types.h is included more than once. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=19042 Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- tools/testing/selftests/filesystems/utils.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/testing/selftests/filesystems/utils.c b/tools/testing/selftests/filesystems/utils.c index e553c89c5b19..06419bf4ba19 100644 --- a/tools/testing/selftests/filesystems/utils.c +++ b/tools/testing/selftests/filesystems/utils.c @@ -3,7 +3,6 @@ #define _GNU_SOURCE #endif #include <fcntl.h> -#include <sys/types.h> #include <dirent.h> #include <grp.h> #include <linux/limits.h> -- 2.32.0.3.g01195cf9f

8 months

1
0
0 0

[PATCH] selftests/mount: Use 'const' for filename parameters

by Ritvik Gupta

The filename parameter in write_file(), maybe_write_file(), and vmaybe_write_file() is unmodified / read-only. So, used 'const' to improve type safety. Signed-off-by: Ritvik Gupta <ritvikfoss(a)gmail.com> --- tools/testing/selftests/mount/unprivileged-remount-test.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/testing/selftests/mount/unprivileged-remount-test.c b/tools/testing/selftests/mount/unprivileged-remount-test.c index d2917054fe3a..e80ac76261e7 100644 --- a/tools/testing/selftests/mount/unprivileged-remount-test.c +++ b/tools/testing/selftests/mount/unprivileged-remount-test.c @@ -54,7 +54,7 @@ static void die(char *fmt, ...) exit(EXIT_FAILURE); } -static void vmaybe_write_file(bool enoent_ok, char *filename, char *fmt, va_list ap) +static void vmaybe_write_file(bool enoent_ok, const char *filename, char *fmt, va_list ap) { char buf[4096]; int fd; @@ -92,7 +92,7 @@ static void vmaybe_write_file(bool enoent_ok, char *filename, char *fmt, va_list } } -static void maybe_write_file(char *filename, char *fmt, ...) +static void maybe_write_file(const char *filename, char *fmt, ...) { va_list ap; @@ -102,7 +102,7 @@ static void maybe_write_file(char *filename, char *fmt, ...) } -static void write_file(char *filename, char *fmt, ...) +static void write_file(const char *filename, char *fmt, ...) { va_list ap; -- 2.48.1

8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror February 2025