- Linux-kselftest-mirror - lists.linaro.org

[PATCH] selftests: propagate CC to selftest submakes

by Andrew Delgadillo

lib.mk defaults to gcc when CC is not set. When building selftests as part of a kernel compilation, MAKEFLAGS is cleared to allow implicit build rules to be used. This has the side-effect of clearing the CC variable, which will cause selftests to be built with gcc regardless of if we are using gcc or clang. To remedy this, propagate the CC variable when clearing makeflags to ensure the correct compiler is used. Signed-off-by: Andrew Delgadillo <adelg(a)google.com> --- tools/testing/selftests/Makefile | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile index d9c283503159..a4dd6d7e8276 100644 --- a/tools/testing/selftests/Makefile +++ b/tools/testing/selftests/Makefile @@ -90,10 +90,12 @@ FORCE_TARGETS ?= # Clear LDFLAGS and MAKEFLAGS when implicit rules are missing. This provides # implicit rules to sub-test Makefiles which avoids build failures in test -# Makefile that don't have explicit build rules. +# Makefile that don't have explicit build rules. Since lib.mk defaults to +# using gcc for compilation when the CC variable is not set, we propagate the +# CC variable so if clang is being used, selftests will build with clang. ifeq (,$(LINK.c)) override LDFLAGS = -override MAKEFLAGS = +override MAKEFLAGS = CC=$(CC) endif # Append kselftest to KBUILD_OUTPUT and O to avoid cluttering -- 2.29.2.576.ga3fc446d84-goog

4 years, 6 months

3
4
0 0

[PATCH] selftests: test_vxlan_under_vrf: mute uncessary error message

by Po-Hsu Lin

The cleanup function in this script that tries to delete hv-1 / hv-2 vm-1 / vm-2 netns will generate some uncessary error messages: Cannot remove namespace file "/run/netns/hv-2": No such file or directory Cannot remove namespace file "/run/netns/vm-1": No such file or directory Cannot remove namespace file "/run/netns/vm-2": No such file or directory Redirect it to /dev/null like other commands in the cleanup function to reduce confusion. Signed-off-by: Po-Hsu Lin <po-hsu.lin(a)canonical.com> --- tools/testing/selftests/net/test_vxlan_under_vrf.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/net/test_vxlan_under_vrf.sh b/tools/testing/selftests/net/test_vxlan_under_vrf.sh index 09f9ed9..534c8b7 100755 --- a/tools/testing/selftests/net/test_vxlan_under_vrf.sh +++ b/tools/testing/selftests/net/test_vxlan_under_vrf.sh @@ -50,7 +50,7 @@ cleanup() { ip link del veth-tap 2>/dev/null || true for ns in hv-1 hv-2 vm-1 vm-2; do - ip netns del $ns || true + ip netns del $ns 2>/dev/null || true done } -- 2.7.4

4 years, 6 months

1
0
0 0

[PATCH bpf-next] selftests/bpf: xsk selftests - adding xdpxceiver to .gitignore

by Weqaar Janjua

This patch adds *xdpxceiver* to selftests/bpf/.gitignore Reported-by: Yonghong Song <yhs(a)fb.com> Suggested-by: Yonghong Song <yhs(a)fb.com> Signed-off-by: Weqaar Janjua <weqaar.a.janjua(a)intel.com> --- tools/testing/selftests/bpf/.gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/bpf/.gitignore b/tools/testing/selftests/bpf/.gitignore index 752d8edddc66..f5b7ef93618c 100644 --- a/tools/testing/selftests/bpf/.gitignore +++ b/tools/testing/selftests/bpf/.gitignore @@ -36,3 +36,4 @@ test_cpp /runqslower /bench *.ko +xdpxceiver -- 2.20.1

4 years, 6 months

2
1
0 0

BPF selftests build failure in 5.10-rc

by Seth Forshee

Building the BPF selftests with clang 11, I'm getting the following error: CLNG-LLC [test_maps] profiler1.o In file included from progs/profiler1.c:6: progs/profiler.inc.h:260:17: error: use of unknown builtin '__builtin_preserve_enum_value' [-Wimplicit-function-declaration] int cgrp_id = bpf_core_enum_value(enum cgroup_subsys_id___local, ^ /home/ubuntu/unstable/tools/testing/selftests/bpf/tools/include/bpf/bpf_core_read.h:179:2: note: expanded from macro 'bpf_core_enum_value' __builtin_preserve_enum_value(*(typeof(enum_type) *)enum_value, BPF_ENUMVAL_VALUE) ^ 1 error generated. llc: error: llc: <stdin>:1:1: error: expected top-level entity BPF obj compilation failed I see that test_core_reloc_enumval.c takes precautions around the use of __builtin_preserve_enum_value as it is currently only available in clang 12 nightlies. Is it possible to do something similar here? Though I see that the use of the builtin is not nearly so neatly localized as it is in test_core_reloc_enumval.c. Thanks, Seth

4 years, 6 months

2
2
0 0

[PATCH bpf-next v4 0/5] selftests/bpf: xsk selftests

by Weqaar Janjua

This patch set adds AF_XDP selftests based on veth to selftests/bpf. # Topology: # --------- # ----------- # _ | Process | _ # / ----------- \ # / | \ # / | \ # ----------- | ----------- # | Thread1 | | | Thread2 | # ----------- | ----------- # | | | # ----------- | ----------- # | xskX | | | xskY | # ----------- | ----------- # | | | # ----------- | ---------- # | vethX | --------- | vethY | # ----------- peer ---------- # | | | # namespaceX | namespaceY These selftests test AF_XDP SKB and Native/DRV modes using veth Virtual Ethernet interfaces. The test program contains two threads, each thread is single socket with a unique UMEM. It validates in-order packet delivery and packet content by sending packets to each other. Prerequisites setup by script test_xsk.sh: Set up veth interfaces as per the topology shown ^^: * setup two veth interfaces and one namespace ** veth<xxxx> in root namespace ** veth<yyyy> in af_xdp<xxxx> namespace ** namespace af_xdp<xxxx> * create a spec file veth.spec that includes this run-time configuration *** xxxx and yyyy are randomly generated 4 digit numbers used to avoid conflict with any existing interface Adds xsk framework test to validate veth xdp DRV and SKB modes. The following tests are provided: 1. AF_XDP SKB mode Generic mode XDP is driver independent, used when the driver does not have support for XDP. Works on any netdevice using sockets and generic XDP path. XDP hook from netif_receive_skb(). a. nopoll - soft-irq processing b. poll - using poll() syscall c. Socket Teardown Create a Tx and a Rx socket, Tx from one socket, Rx on another. Destroy both sockets, then repeat multiple times. Only nopoll mode is used d. Bi-directional Sockets Configure sockets as bi-directional tx/rx sockets, sets up fill and completion rings on each socket, tx/rx in both directions. Only nopoll mode is used 2. AF_XDP DRV/Native mode Works on any netdevice with XDP_REDIRECT support, driver dependent. Processes packets before SKB allocation. Provides better performance than SKB. Driver hook available just after DMA of buffer descriptor. a. nopoll b. poll c. Socket Teardown d. Bi-directional Sockets * Only copy mode is supported because veth does not currently support zero-copy mode Total tests: 8 Flow: * Single process spawns two threads: Tx and Rx * Each of these two threads attach to a veth interface within their assigned namespaces * Each thread creates one AF_XDP socket connected to a unique umem for each veth interface * Tx thread transmits 10k packets from veth<xxxx> to veth<yyyy> * Rx thread verifies if all 10k packets were received and delivered in-order, and have the right content v2 changes: * Move selftests/xsk to selftests/bpf * Remove Makefiles under selftests/xsk, and utilize selftests/bpf/Makefile v3 changes: * merge all test scripts test_xsk_*.sh into test_xsk.sh v4 changes: * merge xsk_env.sh into xsk_prereqs.sh * test_xsk.sh add cliarg -c for color-coded output * test_xsk.sh PREREQUISITES disables IPv6 on veth interfaces * test_xsk.sh PREREQUISITES adds xsk framework test * test_xsk.sh is independently executable * xdpxceiver.c Tx/Rx validates only IPv4 packets with TOS 0x9, ignores others Structure of the patch set: Patch 1: Adds XSK selftests framework and test under selftests/bpf Patch 2: Adds tests: SKB poll and nopoll mode, and mac-ip-udp debug Patch 3: Adds tests: DRV poll and nopoll mode Patch 4: Adds tests: SKB and DRV Socket Teardown Patch 5: Adds tests: SKB and DRV Bi-directional Sockets Thanks: Weqaar Weqaar Janjua (5): selftests/bpf: xsk selftests framework selftests/bpf: xsk selftests - SKB POLL, NOPOLL selftests/bpf: xsk selftests - DRV POLL, NOPOLL selftests/bpf: xsk selftests - Socket Teardown - SKB, DRV selftests/bpf: xsk selftests - Bi-directional Sockets - SKB, DRV tools/testing/selftests/bpf/Makefile | 7 +- tools/testing/selftests/bpf/test_xsk.sh | 259 +++++ tools/testing/selftests/bpf/xdpxceiver.c | 1074 ++++++++++++++++++++ tools/testing/selftests/bpf/xdpxceiver.h | 160 +++ tools/testing/selftests/bpf/xsk_prereqs.sh | 135 +++ 5 files changed, 1633 insertions(+), 2 deletions(-) create mode 100755 tools/testing/selftests/bpf/test_xsk.sh create mode 100644 tools/testing/selftests/bpf/xdpxceiver.c create mode 100644 tools/testing/selftests/bpf/xdpxceiver.h create mode 100755 tools/testing/selftests/bpf/xsk_prereqs.sh -- 2.20.1

4 years, 6 months

4
10
0 0

[PATCH v1] um: Increase stack frame size threshold for signal.c

by Andy Shevchenko

The signal.c can't use heap for bit data located on stack. However, by default a compiler warns us about overstepping stack frame size threshold: arch/um/os-Linux/signal.c: In function ‘sig_handler_common’: arch/um/os-Linux/signal.c:51:1: warning: the frame size of 2960 bytes is larger than 2048 bytes [-Wframe-larger-than=] 51 | } | ^ arch/um/os-Linux/signal.c: In function ‘timer_real_alarm_handler’: arch/um/os-Linux/signal.c:95:1: warning: the frame size of 2960 bytes is larger than 2048 bytes [-Wframe-larger-than=] 95 | } | ^ Due to above increase stack frame size threshold explicitly for signal.c to avoid unnecessary warning. Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- arch/um/os-Linux/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/um/os-Linux/Makefile b/arch/um/os-Linux/Makefile index 839915b8c31c..77ac50baa3f8 100644 --- a/arch/um/os-Linux/Makefile +++ b/arch/um/os-Linux/Makefile @@ -10,6 +10,8 @@ obj-y = execvp.o file.o helper.o irq.o main.o mem.o process.o \ registers.o sigio.o signal.o start_up.o time.o tty.o \ umid.o user_syms.o util.o drivers/ skas/ +CFLAGS_signal.o += -Wframe-larger-than=4096 + obj-$(CONFIG_ARCH_REUSE_HOST_VSYSCALL_AREA) += elf_aux.o USER_OBJS := $(user-objs-y) elf_aux.o execvp.o file.o helper.o irq.o \ -- 2.29.2

4 years, 6 months

2
1
0 0

[PATCH net] selftests: fix poll error in udpgro.sh

by Paolo Abeni

The test program udpgso_bench_rx always invokes the poll() syscall with a timeout of 10ms. If a larger timeout is specified via the command line, udpgso_bench_rx is supposed to do multiple poll() calls till the timeout is expired or an event is received. Currently the poll() loop errors out after the first invocation with no events, and may causes self-tests failure alike: failed GRO with custom segment size ./udpgso_bench_rx: poll: 0x0 expected 0x1 This change addresses the issue allowing the poll() loop to consume all the configured timeout. Fixes: ada641ff6ed3 ("selftests: fixes for UDP GRO") Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> --- tools/testing/selftests/net/udpgso_bench_rx.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/testing/selftests/net/udpgso_bench_rx.c b/tools/testing/selftests/net/udpgso_bench_rx.c index db3d4a8b5a4c..76a24052f4b4 100644 --- a/tools/testing/selftests/net/udpgso_bench_rx.c +++ b/tools/testing/selftests/net/udpgso_bench_rx.c @@ -113,6 +113,9 @@ static void do_poll(int fd, int timeout_ms) interrupted = true; break; } + + /* no events and more time to wait, do poll again */ + continue; } if (pfd.revents != POLLIN) error(1, errno, "poll: 0x%x expected 0x%x\n", -- 2.26.2

4 years, 6 months

1
0
0 0

Fwd: [PROBLEM] kmemleak: 2 new suspected memory leaks

by Jeffrin Jose T

4 years, 6 months

1
0
0 0

[PATCH v4] self_tests/kvm: sync_regs test for diag318

by Collin Walling

The DIAGNOSE 0x0318 instruction, unique to s390x, is a privileged call that must be intercepted via SIE, handled in userspace, and the information set by the instruction is communicated back to KVM. To test the instruction interception, an ad-hoc handler is defined which simply has a VM execute the instruction and then userspace will extract the necessary info. The handler is defined such that the instruction invocation occurs only once. It is up to the caller to determine how the info returned by this handler should be used. The diag318 info is communicated from userspace to KVM via a sync_regs call. This is tested During a sync_regs test, where the diag318 info is requested via the handler, then the info is stored in the appropriate register in KVM via a sync registers call. If KVM does not support diag318, then the tests will print a message stating that diag318 was skipped, and the asserts will simply test against a value of 0. Signed-off-by: Collin Walling <walling(a)linux.ibm.com> --- tools/testing/selftests/kvm/Makefile | 2 +- .../kvm/include/s390x/diag318_test_handler.h | 13 +++ .../kvm/lib/s390x/diag318_test_handler.c | 82 +++++++++++++++++++ .../selftests/kvm/s390x/sync_regs_test.c | 16 +++- 4 files changed, 111 insertions(+), 2 deletions(-) create mode 100644 tools/testing/selftests/kvm/include/s390x/diag318_test_handler.h create mode 100644 tools/testing/selftests/kvm/lib/s390x/diag318_test_handler.c diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile index 3d14ef77755e..426c78449044 100644 --- a/tools/testing/selftests/kvm/Makefile +++ b/tools/testing/selftests/kvm/Makefile @@ -36,7 +36,7 @@ endif LIBKVM = lib/assert.c lib/elf.c lib/io.c lib/kvm_util.c lib/sparsebit.c lib/test_util.c LIBKVM_x86_64 = lib/x86_64/processor.c lib/x86_64/vmx.c lib/x86_64/svm.c lib/x86_64/ucall.c lib/x86_64/handlers.S LIBKVM_aarch64 = lib/aarch64/processor.c lib/aarch64/ucall.c -LIBKVM_s390x = lib/s390x/processor.c lib/s390x/ucall.c +LIBKVM_s390x = lib/s390x/processor.c lib/s390x/ucall.c lib/s390x/diag318_test_handler.c TEST_GEN_PROGS_x86_64 = x86_64/cr4_cpuid_sync_test TEST_GEN_PROGS_x86_64 += x86_64/evmcs_test diff --git a/tools/testing/selftests/kvm/include/s390x/diag318_test_handler.h b/tools/testing/selftests/kvm/include/s390x/diag318_test_handler.h new file mode 100644 index 000000000000..b0ed71302722 --- /dev/null +++ b/tools/testing/selftests/kvm/include/s390x/diag318_test_handler.h @@ -0,0 +1,13 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later + * + * Test handler for the s390x DIAGNOSE 0x0318 instruction. + * + * Copyright (C) 2020, IBM + */ + +#ifndef SELFTEST_KVM_DIAG318_TEST_HANDLER +#define SELFTEST_KVM_DIAG318_TEST_HANDLER + +uint64_t get_diag318_info(void); + +#endif diff --git a/tools/testing/selftests/kvm/lib/s390x/diag318_test_handler.c b/tools/testing/selftests/kvm/lib/s390x/diag318_test_handler.c new file mode 100644 index 000000000000..86b9e611ad87 --- /dev/null +++ b/tools/testing/selftests/kvm/lib/s390x/diag318_test_handler.c @@ -0,0 +1,82 @@ +// SPDX-License-Identifier: GPL-2.0-or-later +/* + * Test handler for the s390x DIAGNOSE 0x0318 instruction. + * + * Copyright (C) 2020, IBM + */ + +#include "test_util.h" +#include "kvm_util.h" + +#define VCPU_ID 6 + +#define ICPT_INSTRUCTION 0x04 +#define IPA0_DIAG 0x8300 + +static void guest_code(void) +{ + uint64_t diag318_info = 0x12345678; + + asm volatile ("diag %0,0,0x318\n" : : "d" (diag318_info)); +} + +/* + * The DIAGNOSE 0x0318 instruction call must be handled via userspace. As such, + * we create an ad-hoc VM here to handle the instruction then extract the + * necessary data. It is up to the caller to decide what to do with that data. + */ +static uint64_t diag318_handler(void) +{ + struct kvm_vm *vm; + struct kvm_run *run; + uint64_t reg; + uint64_t diag318_info; + + vm = vm_create_default(VCPU_ID, 0, guest_code); + vcpu_run(vm, VCPU_ID); + run = vcpu_state(vm, VCPU_ID); + + TEST_ASSERT(run->exit_reason == KVM_EXIT_S390_SIEIC, + "DIAGNOSE 0x0318 instruction was not intercepted"); + TEST_ASSERT(run->s390_sieic.icptcode == ICPT_INSTRUCTION, + "Unexpected intercept code: 0x%x", run->s390_sieic.icptcode); + TEST_ASSERT((run->s390_sieic.ipa & 0xff00) == IPA0_DIAG, + "Unexpected IPA0 code: 0x%x", (run->s390_sieic.ipa & 0xff00)); + + reg = (run->s390_sieic.ipa & 0x00f0) >> 4; + diag318_info = run->s.regs.gprs[reg]; + + TEST_ASSERT(diag318_info != 0, "DIAGNOSE 0x0318 info not set"); + + kvm_vm_free(vm); + + return diag318_info; +} + +uint64_t get_diag318_info(void) +{ + static uint64_t diag318_info; + static bool printed_skip; + + /* + * If KVM does not support diag318, then return 0 to + * ensure tests do not break. + */ + if (!kvm_check_cap(KVM_CAP_S390_DIAG318)) { + if (!printed_skip) { + fprintf(stdout, "KVM_CAP_S390_DIAG318 not supported. " + "Skipping diag318 test.\n"); + printed_skip = true; + } + return 0; + } + + /* + * If a test has previously requested the diag318 info, + * then don't bother spinning up a temporary VM again. + */ + if (!diag318_info) + diag318_info = diag318_handler(); + + return diag318_info; +} diff --git a/tools/testing/selftests/kvm/s390x/sync_regs_test.c b/tools/testing/selftests/kvm/s390x/sync_regs_test.c index 5731ccf34917..caf7b8859a94 100644 --- a/tools/testing/selftests/kvm/s390x/sync_regs_test.c +++ b/tools/testing/selftests/kvm/s390x/sync_regs_test.c @@ -20,6 +20,7 @@ #include "test_util.h" #include "kvm_util.h" +#include "diag318_test_handler.h" #define VCPU_ID 5 @@ -70,7 +71,7 @@ static void compare_sregs(struct kvm_sregs *left, struct kvm_sync_regs *right) #undef REG_COMPARE -#define TEST_SYNC_FIELDS (KVM_SYNC_GPRS|KVM_SYNC_ACRS|KVM_SYNC_CRS) +#define TEST_SYNC_FIELDS (KVM_SYNC_GPRS|KVM_SYNC_ACRS|KVM_SYNC_CRS|KVM_SYNC_DIAG318) #define INVALID_SYNC_FIELD 0x80000000 int main(int argc, char *argv[]) @@ -152,6 +153,12 @@ int main(int argc, char *argv[]) run->kvm_valid_regs = TEST_SYNC_FIELDS; run->kvm_dirty_regs = KVM_SYNC_GPRS | KVM_SYNC_ACRS; + + if (get_diag318_info() > 0) { + run->s.regs.diag318 = get_diag318_info(); + run->kvm_dirty_regs |= KVM_SYNC_DIAG318; + } + rv = _vcpu_run(vm, VCPU_ID); TEST_ASSERT(rv == 0, "vcpu_run failed: %d\n", rv); TEST_ASSERT(run->exit_reason == KVM_EXIT_S390_SIEIC, @@ -164,6 +171,9 @@ int main(int argc, char *argv[]) TEST_ASSERT(run->s.regs.acrs[0] == 1 << 11, "acr0 sync regs value incorrect 0x%x.", run->s.regs.acrs[0]); + TEST_ASSERT(run->s.regs.diag318 == get_diag318_info(), + "diag318 sync regs value incorrect 0x%llx.", + run->s.regs.diag318); vcpu_regs_get(vm, VCPU_ID, &regs); compare_regs(&regs, &run->s.regs); @@ -177,6 +187,7 @@ int main(int argc, char *argv[]) run->kvm_valid_regs = TEST_SYNC_FIELDS; run->kvm_dirty_regs = 0; run->s.regs.gprs[11] = 0xDEADBEEF; + run->s.regs.diag318 = 0x4B1D; rv = _vcpu_run(vm, VCPU_ID); TEST_ASSERT(rv == 0, "vcpu_run failed: %d\n", rv); TEST_ASSERT(run->exit_reason == KVM_EXIT_S390_SIEIC, @@ -186,6 +197,9 @@ int main(int argc, char *argv[]) TEST_ASSERT(run->s.regs.gprs[11] != 0xDEADBEEF, "r11 sync regs value incorrect 0x%llx.", run->s.regs.gprs[11]); + TEST_ASSERT(run->s.regs.diag318 != 0x4B1D, + "diag318 sync regs value incorrect 0x%llx.", + run->s.regs.diag318); kvm_vm_free(vm); -- 2.26.2

4 years, 7 months

4
12
0 0

Re: [PATCH bpf-next v3 1/5] selftests/bpf: xsk selftests framework

by Weqaar Janjua

On Fri, 27 Nov 2020 at 04:19, Yonghong Song <yhs(a)fb.com> wrote: > > > > On 11/26/20 1:22 PM, Weqaar Janjua wrote: > > On Thu, 26 Nov 2020 at 09:01, Björn Töpel <bjorn.topel(a)intel.com> wrote: > >> > >> On 2020-11-26 07:44, Yonghong Song wrote: > >>> > >> [...] > >>> > >>> What other configures I am missing? > >>> > >>> BTW, I cherry-picked the following pick from bpf tree in this experiment. > >>> commit e7f4a5919bf66e530e08ff352d9b78ed89574e6b (HEAD -> xsk) > >>> Author: Björn Töpel <bjorn.topel(a)intel.com> > >>> Date: Mon Nov 23 18:56:00 2020 +0100 > >>> > >>> net, xsk: Avoid taking multiple skbuff references > >>> > >> > >> Hmm, I'm getting an oops, unless I cherry-pick: > >> > >> 36ccdf85829a ("net, xsk: Avoid taking multiple skbuff references") > >> > >> *AND* > >> > >> 537cf4e3cc2f ("xsk: Fix umem cleanup bug at socket destruct") > >> > >> from bpf/master. > >> > > > > Same as Bjorn's findings ^^^, additionally applying the second patch > > 537cf4e3cc2f [PASS] all tests for me > > > > PREREQUISITES: [ PASS ] > > SKB NOPOLL: [ PASS ] > > SKB POLL: [ PASS ] > > DRV NOPOLL: [ PASS ] > > DRV POLL: [ PASS ] > > SKB SOCKET TEARDOWN: [ PASS ] > > DRV SOCKET TEARDOWN: [ PASS ] > > SKB BIDIRECTIONAL SOCKETS: [ PASS ] > > DRV BIDIRECTIONAL SOCKETS: [ PASS ] > > > > With the first patch alone, as soon as we enter DRV/Native NOPOLL mode > > kernel panics, whereas in your case NOPOLL tests were falling with > > packets being *lost* as per seqnum mismatch. > > > > Can you please test this out with both patches and let us know? > > I applied both the above patches in bpf-next as well as this patch set, > I still see failures. I am attaching my config file. Maybe you can take > a look at what is the issue. > Thanks for the config, can you please confirm the compiler version, and resource limits i.e. stack size, memory, etc.? Only NOPOLL tests are failing for you as I see it, do the same tests fail every time? I will need to spend some time debugging this to have a fix. Thanks, /Weqaar > > > >> Can I just run test_xsk.sh at tools/testing/selftests/bpf/ directory? > >> This will be easier than the above for bpf developers. If it does not > >> work, I would like to recommend to make it work. > >> > > yes test_xsk.shis self contained, will update the instructions in there with v4. > > That will be great. Thanks! > > > > > Thanks, > > /Weqaar > >> > >> Björn

4 years, 7 months

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror