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

[PATCH] kselftest/arm64: Check that SVCR is 0 in signal handlers

by Mark Brown

We don't currently validate that we exit streaming mode and clear ZA when we enter a signal handler. Add simple checks for this in the SSVE and ZA tests. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- tools/testing/selftests/arm64/signal/sve_helpers.h | 13 +++++++++++++ tools/testing/selftests/arm64/signal/testcases/ssve_regs.c | 5 +++++ tools/testing/selftests/arm64/signal/testcases/za_regs.c | 5 +++++ 3 files changed, 23 insertions(+) diff --git a/tools/testing/selftests/arm64/signal/sve_helpers.h b/tools/testing/selftests/arm64/signal/sve_helpers.h index 50948ce471cc620118a0c7c8df70d66dbdfbb160..ca133b93375fa587b5e02cd76b2f2fcd92591723 100644 --- a/tools/testing/selftests/arm64/signal/sve_helpers.h +++ b/tools/testing/selftests/arm64/signal/sve_helpers.h @@ -18,4 +18,17 @@ extern unsigned int nvls; int sve_fill_vls(bool use_sme, int min_vls); +static inline uint64_t get_svcr(void) +{ + uint64_t val; + + asm volatile ( + "mrs %0, S3_3_C4_C2_2\n" + : "=r"(val) + : + : "cc"); + + return val; +} + #endif diff --git a/tools/testing/selftests/arm64/signal/testcases/ssve_regs.c b/tools/testing/selftests/arm64/signal/testcases/ssve_regs.c index 6dbe48cf8b09ed8b7a5ab47690bd87e39e18e1e6..3dee68fa36d1cf2716f54d5f328b3f4077493c3b 100644 --- a/tools/testing/selftests/arm64/signal/testcases/ssve_regs.c +++ b/tools/testing/selftests/arm64/signal/testcases/ssve_regs.c @@ -85,6 +85,11 @@ static int do_one_sme_vl(struct tdescr *td, siginfo_t *si, ucontext_t *uc, fprintf(stderr, "Got expected size %u and VL %d\n", head->size, ssve->vl); + if (get_svcr() != 0) { + fprintf(stderr, "Unexpected SVCR %llx\n", get_svcr()); + return 1; + } + return 0; } diff --git a/tools/testing/selftests/arm64/signal/testcases/za_regs.c b/tools/testing/selftests/arm64/signal/testcases/za_regs.c index b9e13f27f1f9aaf55db2a5e391f360993561d0b7..9fff4c50030414d06157e0da0c29fd794f707309 100644 --- a/tools/testing/selftests/arm64/signal/testcases/za_regs.c +++ b/tools/testing/selftests/arm64/signal/testcases/za_regs.c @@ -91,6 +91,11 @@ static int do_one_sme_vl(struct tdescr *td, siginfo_t *si, ucontext_t *uc, return 1; } + if (get_svcr() != 0) { + fprintf(stderr, "Unexpected SVCR %llx\n", get_svcr()); + return 1; + } + return 0; } --- base-commit: 8e929cb546ee42c9a61d24fae60605e9e3192354 change-id: 20241106-arm64-fpmr-signal-test-c0a0c5bf0174 Best regards, -- Mark Brown <broonie(a)kernel.org>

11 months

2
3
0 0

[PATCH 0/2] kselftest/arm64: Avoid detecting spurious PAC key collisions

by Mark Brown

The PAC tests currently generate a very small number of false failures since the limited size of PAC keys, especially with fewer bits allocated for PAC due to larger VA, means collisions in generated PACs are possible even if the PAC keys are different. The test tries to work around this by testing repeatedly but doesn't iterate often enough to be reliable. We also fix a leak of file descriptors in the exec test which doesn't matter now but can become an issue when the number of iterations is increased, we can bump into limits on allocated file descriptors. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- Mark Brown (2): kselftest/arm64: Don't leak pipe fds in pac.exec_sign_all() kselftest/arm64: Try harder to generate different keys during PAC tests tools/testing/selftests/arm64/pauth/pac.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- base-commit: 8e929cb546ee42c9a61d24fae60605e9e3192354 change-id: 20241111-arm64-pac-test-collisions-5613f5dfe479 Best regards, -- Mark Brown <broonie(a)kernel.org>

11 months

2
3
0 0

[PATCH 0/4] kselftest/arm64: fp-ptrace enhancements

by Mark Brown

This series contains a bit of a grab bag of improvements to the floating point tests, mainly fp-ptrace. Globally over all the tests we start using defines from the generated sysregs (following the example of the KVM selftests) for SVCR, stop being quite so wasteful with registers when calling into the assembler code then expand the coverage of both ZA writes and FPMR (which was not there since fp-ptrace and the 2023 dpISA extensions were on the list at the same time). Signed-off-by: Mark Brown <broonie(a)kernel.org> --- Mark Brown (4): kselftets/arm64: Use flag bits for features in fp-ptrace assembler code kselftest/arm64: Use a define for SVCR kselftest/arm64: Expand the set of ZA writes fp-ptrace does kselftest/arm64: Add FPMR coverage to fp-ptrace tools/testing/selftests/arm64/fp/Makefile | 20 ++- tools/testing/selftests/arm64/fp/fp-ptrace-asm.S | 52 +++++--- tools/testing/selftests/arm64/fp/fp-ptrace.c | 155 +++++++++++++++++++++-- tools/testing/selftests/arm64/fp/fp-ptrace.h | 16 ++- tools/testing/selftests/arm64/fp/sve-test.S | 5 +- tools/testing/selftests/arm64/fp/za-fork-asm.S | 3 +- tools/testing/selftests/arm64/fp/za-test.S | 6 +- tools/testing/selftests/arm64/fp/zt-test.S | 5 +- 8 files changed, 213 insertions(+), 49 deletions(-) --- base-commit: 8e929cb546ee42c9a61d24fae60605e9e3192354 change-id: 20241105-arm64-fp-ptrace-fpmr-ff061facd3da Best regards, -- Mark Brown <broonie(a)kernel.org>

11 months

2
6
0 0

[PATCH] kunit: skb: add gfp to kernel doc for kunit_zalloc_skb()

by Dan Carpenter

Kuan-Wei Chiu pointed out that the kernel doc for kunit_zalloc_skb() needs to include the @gfp information. Add it. Reported-by: Kuan-Wei Chiu <visitorckw(a)gmail.com> Closes: https://lore.kernel.org/all/Zy+VIXDPuU613fFd@visitorckw-System-Product-Name/ Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> --- include/kunit/skbuff.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/kunit/skbuff.h b/include/kunit/skbuff.h index 345e1e8f0312..07784694357c 100644 --- a/include/kunit/skbuff.h +++ b/include/kunit/skbuff.h @@ -20,8 +20,9 @@ static void kunit_action_kfree_skb(void *p) * kunit_zalloc_skb() - Allocate and initialize a resource managed skb. * @test: The test case to which the skb belongs * @len: size to allocate + * @gfp: allocation flags * - * Allocate a new struct sk_buff with GFP_KERNEL, zero fill the give length + * Allocate a new struct sk_buff with gfp flags, zero fill the given length * and add it as a resource to the kunit test for automatic cleanup. * * Returns: newly allocated SKB, or %NULL on error -- 2.45.2

11 months

3
2
0 0

[PATCH net-next v2 0/8] net: Improve netns handling in RTNL and ip_tunnel

by Xiao Liang

This patch series includes some netns-related improvements and fixes for RTNL and ip_tunnel, to make link creation more intuitive: - Creating link in another net namespace doesn't conflict with link names in current one. - Add a flag in rtnl_ops, to avoid netns change when link-netns is present if possible. - When creating ip tunnel (e.g. GRE) in another netns, use current as link-netns if not specified explicitly. So that # modprobe ip_gre netns_atomic=1 # ip link add netns ns1 link-netns ns2 tun0 type gre ... will create tun0 in ns1, rather than create it in ns2 and move to ns1. And don't conflict with another interface named "tun0" in current netns. --- v2: - Check NLM_F_EXCL to ensure only link creation is affected. - Add self tests for link name/ifindex conflict and notifications in different netns. - Changes in dummy driver and ynl in order to add the test case. v1: link: https://lore.kernel.org/all/20241023023146.372653-1-shaw.leon@gmail.com/ Xiao Liang (8): rtnetlink: Lookup device in target netns when creating link rtnetlink: Add netns_atomic flag in rtnl_link_ops net: ip_tunnel: Build flow in underlay net namespace net: ip_tunnel: Add source netns support for newlink net: ip_gre: Add netns_atomic module parameter net: dummy: Set netns_atomic in rtnl ops for testing tools/net/ynl: Add retry limit for async notification selftests: net: Add two test cases for link netns drivers/net/dummy.c | 1 + include/net/ip_tunnels.h | 3 ++ include/net/rtnetlink.h | 3 ++ net/core/rtnetlink.c | 17 +++++-- net/ipv4/ip_gre.c | 15 +++++- net/ipv4/ip_tunnel.c | 27 +++++++---- tools/net/ynl/lib/ynl.py | 7 ++- tools/testing/selftests/net/Makefile | 1 + tools/testing/selftests/net/netns-name.sh | 10 ++++ tools/testing/selftests/net/netns_atomic.py | 54 +++++++++++++++++++++ 10 files changed, 121 insertions(+), 17 deletions(-) create mode 100755 tools/testing/selftests/net/netns_atomic.py -- 2.47.0

11 months

4
25
0 0

[PATCH net-next v10] net: ipv4: Cache pmtu for all packet paths if multipath enabled

by Vladimir Vdovin

Check number of paths by fib_info_num_path(), and update_or_create_fnhe() for every path. Problem is that pmtu is cached only for the oif that has received icmp message "need to frag", other oifs will still try to use "default" iface mtu. An example topology showing the problem: | host1 +---------+ | dummy0 | 10.179.20.18/32 mtu9000 +---------+ +-----------+----------------+ +---------+ +---------+ | ens17f0 | 10.179.2.141/31 | ens17f1 | 10.179.2.13/31 +---------+ +---------+ | (all here have mtu 9000) | +------+ +------+ | ro1 | 10.179.2.140/31 | ro2 | 10.179.2.12/31 +------+ +------+ | | ---------+------------+-------------------+------ | +-----+ | ro3 | 10.10.10.10 mtu1500 +-----+ | ======================================== some networks ======================================== | +-----+ | eth0| 10.10.30.30 mtu9000 +-----+ | host2 host1 have enabled multipath and sysctl net.ipv4.fib_multipath_hash_policy = 1: default proto static src 10.179.20.18 nexthop via 10.179.2.12 dev ens17f1 weight 1 nexthop via 10.179.2.140 dev ens17f0 weight 1 When host1 tries to do pmtud from 10.179.20.18/32 to host2, host1 receives at ens17f1 iface an icmp packet from ro3 that ro3 mtu=1500. And host1 caches it in nexthop exceptions cache. Problem is that it is cached only for the iface that has received icmp, and there is no way that ro3 will send icmp msg to host1 via another path. Host1 now have this routes to host2: ip r g 10.10.30.30 sport 30000 dport 443 10.10.30.30 via 10.179.2.12 dev ens17f1 src 10.179.20.18 uid 0 cache expires 521sec mtu 1500 ip r g 10.10.30.30 sport 30033 dport 443 10.10.30.30 via 10.179.2.140 dev ens17f0 src 10.179.20.18 uid 0 cache So when host1 tries again to reach host2 with mtu>1500, if packet flow is lucky enough to be hashed with oif=ens17f1 its ok, if oif=ens17f0 it blackholes and still gets icmp msgs from ro3 to ens17f1, until lucky day when ro3 will send it through another flow to ens17f0. Signed-off-by: Vladimir Vdovin <deliran(a)verdict.gg> --- V10: selfttests in pmtu.sh: - remove unused fail var - Flip error messages V9: selftests in pmtu.sh: - remove useless return - fix mtu var override V8: selftests in pmtu.sh: - Change var names from "dummy" to "host" - Fix errors caused by incorrect iface arguments pass - Add src addr to setup_multipath_new - Change multipath* func order - Change route_get_dst_exception() && route_get_dst_pmtu_from_exception() and arguments pass where they are used as Ido suggested in https://lore.kernel.org/all/ZykH_fdcMBdFgXix@shredder/ V7: selftest in pmtu.sh: - add setup_multipath() with old and new nh tests - add global "dummy_v4" addr variables - add documentation - remove dummy netdev usage in mp nh test - remove useless sysctl opts in mp nh test V6: - make commit message cleaner V5: - make self test cleaner V4: - fix selftest, do route lookup before checking cached exceptions V3: - add selftest - fix compile error V2: - fix fib_info_num_path parameter pass --- net/ipv4/route.c | 13 ++++ tools/testing/selftests/net/pmtu.sh | 112 +++++++++++++++++++++++----- 2 files changed, 108 insertions(+), 17 deletions(-) diff --git a/net/ipv4/route.c b/net/ipv4/route.c index 723ac9181558..652f603d29fe 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -1027,6 +1027,19 @@ static void __ip_rt_update_pmtu(struct rtable *rt, struct flowi4 *fl4, u32 mtu) struct fib_nh_common *nhc; fib_select_path(net, &res, fl4, NULL); +#ifdef CONFIG_IP_ROUTE_MULTIPATH + if (fib_info_num_path(res.fi) > 1) { + int nhsel; + + for (nhsel = 0; nhsel < fib_info_num_path(res.fi); nhsel++) { + nhc = fib_info_nhc(res.fi, nhsel); + update_or_create_fnhe(nhc, fl4->daddr, 0, mtu, lock, + jiffies + net->ipv4.ip_rt_mtu_expires); + } + rcu_read_unlock(); + return; + } +#endif /* CONFIG_IP_ROUTE_MULTIPATH */ nhc = FIB_RES_NHC(res); update_or_create_fnhe(nhc, fl4->daddr, 0, mtu, lock, jiffies + net->ipv4.ip_rt_mtu_expires); diff --git a/tools/testing/selftests/net/pmtu.sh b/tools/testing/selftests/net/pmtu.sh index 569bce8b6383..7ca2fbd971ae 100755 --- a/tools/testing/selftests/net/pmtu.sh +++ b/tools/testing/selftests/net/pmtu.sh @@ -197,6 +197,12 @@ # # - pmtu_ipv6_route_change # Same as above but with IPv6 +# +# - pmtu_ipv4_mp_exceptions +# Use the same topology as in pmtu_ipv4, but add routeable addresses +# on host A and B on lo reachable via both routers. Host A and B +# addresses have multipath routes to each other, b_r1 mtu = 1500. +# Check that PMTU exceptions are created for both paths. source lib.sh source net_helper.sh @@ -266,7 +272,8 @@ tests=" list_flush_ipv4_exception ipv4: list and flush cached exceptions 1 list_flush_ipv6_exception ipv6: list and flush cached exceptions 1 pmtu_ipv4_route_change ipv4: PMTU exception w/route replace 1 - pmtu_ipv6_route_change ipv6: PMTU exception w/route replace 1" + pmtu_ipv6_route_change ipv6: PMTU exception w/route replace 1 + pmtu_ipv4_mp_exceptions ipv4: PMTU multipath nh exceptions 1" # Addressing and routing for tests with routers: four network segments, with # index SEGMENT between 1 and 4, a common prefix (PREFIX4 or PREFIX6) and an @@ -343,6 +350,9 @@ tunnel6_a_addr="fd00:2::a" tunnel6_b_addr="fd00:2::b" tunnel6_mask="64" +host4_a_addr="192.168.99.99" +host4_b_addr="192.168.88.88" + dummy6_0_prefix="fc00:1000::" dummy6_1_prefix="fc00:1001::" dummy6_mask="64" @@ -984,6 +994,52 @@ setup_ovs_bridge() { run_cmd ip route add ${prefix6}:${b_r1}::1 via ${prefix6}:${a_r1}::2 } +setup_multipath_new() { + # Set up host A with multipath routes to host B host4_b_addr + run_cmd ${ns_a} ip addr add ${host4_a_addr} dev lo + run_cmd ${ns_a} ip nexthop add id 401 via ${prefix4}.${a_r1}.2 dev veth_A-R1 + run_cmd ${ns_a} ip nexthop add id 402 via ${prefix4}.${a_r2}.2 dev veth_A-R2 + run_cmd ${ns_a} ip nexthop add id 403 group 401/402 + run_cmd ${ns_a} ip route add ${host4_b_addr} src ${host4_a_addr} nhid 403 + + # Set up host B with multipath routes to host A host4_a_addr + run_cmd ${ns_b} ip addr add ${host4_b_addr} dev lo + run_cmd ${ns_b} ip nexthop add id 401 via ${prefix4}.${b_r1}.2 dev veth_B-R1 + run_cmd ${ns_b} ip nexthop add id 402 via ${prefix4}.${b_r2}.2 dev veth_B-R2 + run_cmd ${ns_b} ip nexthop add id 403 group 401/402 + run_cmd ${ns_b} ip route add ${host4_a_addr} src ${host4_b_addr} nhid 403 +} + +setup_multipath_old() { + # Set up host A with multipath routes to host B host4_b_addr + run_cmd ${ns_a} ip addr add ${host4_a_addr} dev lo + run_cmd ${ns_a} ip route add ${host4_b_addr} \ + src ${host4_a_addr} \ + nexthop via ${prefix4}.${a_r1}.2 weight 1 \ + nexthop via ${prefix4}.${a_r2}.2 weight 1 + + # Set up host B with multipath routes to host A host4_a_addr + run_cmd ${ns_b} ip addr add ${host4_b_addr} dev lo + run_cmd ${ns_b} ip route add ${host4_a_addr} \ + src ${host4_b_addr} \ + nexthop via ${prefix4}.${b_r1}.2 weight 1 \ + nexthop via ${prefix4}.${b_r2}.2 weight 1 +} + +setup_multipath() { + if [ "$USE_NH" = "yes" ]; then + setup_multipath_new + else + setup_multipath_old + fi + + # Set up routers with routes to dummies + run_cmd ${ns_r1} ip route add ${host4_a_addr} via ${prefix4}.${a_r1}.1 + run_cmd ${ns_r2} ip route add ${host4_a_addr} via ${prefix4}.${a_r2}.1 + run_cmd ${ns_r1} ip route add ${host4_b_addr} via ${prefix4}.${b_r1}.1 + run_cmd ${ns_r2} ip route add ${host4_b_addr} via ${prefix4}.${b_r2}.1 +} + setup() { [ "$(id -u)" -ne 0 ] && echo " need to run as root" && return $ksft_skip @@ -1076,23 +1132,15 @@ link_get_mtu() { } route_get_dst_exception() { - ns_cmd="${1}" - dst="${2}" - dsfield="${3}" + ns_cmd="${1}"; shift - if [ -z "${dsfield}" ]; then - dsfield=0 - fi - - ${ns_cmd} ip route get "${dst}" dsfield "${dsfield}" + ${ns_cmd} ip route get "$@" } route_get_dst_pmtu_from_exception() { - ns_cmd="${1}" - dst="${2}" - dsfield="${3}" + ns_cmd="${1}"; shift - mtu_parse "$(route_get_dst_exception "${ns_cmd}" "${dst}" "${dsfield}")" + mtu_parse "$(route_get_dst_exception "${ns_cmd}" "$@")" } check_pmtu_value() { @@ -1235,10 +1283,10 @@ test_pmtu_ipv4_dscp_icmp_exception() { run_cmd "${ns_a}" ping -q -M want -Q "${dsfield}" -c 1 -w 1 -s "${len}" "${dst2}" # Check that exceptions have been created with the correct PMTU - pmtu_1="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst1}" "${policy_mark}")" + pmtu_1="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst1}" dsfield "${policy_mark}")" check_pmtu_value "1400" "${pmtu_1}" "exceeding MTU" || return 1 - pmtu_2="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst2}" "${policy_mark}")" + pmtu_2="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst2}" dsfield "${policy_mark}")" check_pmtu_value "1500" "${pmtu_2}" "exceeding MTU" || return 1 } @@ -1285,9 +1333,9 @@ test_pmtu_ipv4_dscp_udp_exception() { UDP:"${dst2}":50000,tos="${dsfield}" # Check that exceptions have been created with the correct PMTU - pmtu_1="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst1}" "${policy_mark}")" + pmtu_1="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst1}" dsfield "${policy_mark}")" check_pmtu_value "1400" "${pmtu_1}" "exceeding MTU" || return 1 - pmtu_2="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst2}" "${policy_mark}")" + pmtu_2="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst2}" dsfield "${policy_mark}")" check_pmtu_value "1500" "${pmtu_2}" "exceeding MTU" || return 1 } @@ -2329,6 +2377,36 @@ test_pmtu_ipv6_route_change() { test_pmtu_ipvX_route_change 6 } +test_pmtu_ipv4_mp_exceptions() { + setup namespaces routing multipath || return $ksft_skip + + trace "${ns_a}" veth_A-R1 "${ns_r1}" veth_R1-A \ + "${ns_r1}" veth_R1-B "${ns_b}" veth_B-R1 \ + "${ns_a}" veth_A-R2 "${ns_r2}" veth_R2-A \ + "${ns_r2}" veth_R2-B "${ns_b}" veth_B-R2 + + # Set up initial MTU values + mtu "${ns_a}" veth_A-R1 2000 + mtu "${ns_r1}" veth_R1-A 2000 + mtu "${ns_r1}" veth_R1-B 1500 + mtu "${ns_b}" veth_B-R1 1500 + + mtu "${ns_a}" veth_A-R2 2000 + mtu "${ns_r2}" veth_R2-A 2000 + mtu "${ns_r2}" veth_R2-B 1500 + mtu "${ns_b}" veth_B-R2 1500 + + # Ping and expect two nexthop exceptions for two routes + run_cmd ${ns_a} ping -q -M want -i 0.1 -c 1 -s 1800 "${host4_b_addr}" + + # Check that exceptions have been created with the correct PMTU + pmtu_a_R1="$(route_get_dst_pmtu_from_exception "${ns_a}" "${host4_b_addr}" oif veth_A-R1)" + pmtu_a_R2="$(route_get_dst_pmtu_from_exception "${ns_a}" "${host4_b_addr}" oif veth_A-R2)" + + check_pmtu_value "1500" "${pmtu_a_R1}" "exceeding MTU (veth_A-R1)" || return 1 + check_pmtu_value "1500" "${pmtu_a_R2}" "exceeding MTU (veth_A-R2)" || return 1 +} + usage() { echo echo "$0 [OPTIONS] [TEST]..." base-commit: 66600fac7a984dea4ae095411f644770b2561ede -- 2.43.5

11 months

3
2
0 0

[PATCH net-next] net: netconsole: selftests: Check if netdevsim is available

by Breno Leitao

The netconsole selftest relies on the availability of the netdevsim module. To ensure the test can run correctly, we need to check if the netdevsim module is either loaded or built-in before proceeding. Update the netconsole selftest to check for the existence of the /sys/bus/netdevsim/new_device file before running the test. If the file is not found, the test is skipped with an explanation that the CONFIG_NETDEVSIM kernel config option may not be enabled. Signed-off-by: Breno Leitao <leitao(a)debian.org> --- tools/testing/selftests/drivers/net/netcons_basic.sh | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/drivers/net/netcons_basic.sh b/tools/testing/selftests/drivers/net/netcons_basic.sh index 182eb1a97e59f3b4c9eea0e5b9e64a7fff656e2b..b175f4d966e5056ddb62e335f212c03e55f50fb0 100755 --- a/tools/testing/selftests/drivers/net/netcons_basic.sh +++ b/tools/testing/selftests/drivers/net/netcons_basic.sh @@ -39,6 +39,7 @@ NAMESPACE="" # IDs for netdevsim NSIM_DEV_1_ID=$((256 + RANDOM % 256)) NSIM_DEV_2_ID=$((512 + RANDOM % 256)) +NSIM_DEV_SYS_NEW="/sys/bus/netdevsim/new_device" # Used to create and delete namespaces source "${SCRIPTDIR}"/../../net/lib.sh @@ -46,7 +47,6 @@ source "${SCRIPTDIR}"/../../net/net_helper.sh # Create netdevsim interfaces create_ifaces() { - local NSIM_DEV_SYS_NEW=/sys/bus/netdevsim/new_device echo "$NSIM_DEV_2_ID" > "$NSIM_DEV_SYS_NEW" echo "$NSIM_DEV_1_ID" > "$NSIM_DEV_SYS_NEW" @@ -212,6 +212,11 @@ function check_for_dependencies() { exit "${ksft_skip}" fi + if [ ! -f "${NSIM_DEV_SYS_NEW}" ]; then + echo "SKIP: file ${NSIM_DEV_SYS_NEW} does not exist. Check if CONFIG_NETDEVSIM is enabled" >&2 + exit "${ksft_skip}" + fi + if [ ! -d "${NETCONS_CONFIGFS}" ]; then echo "SKIP: directory ${NETCONS_CONFIGFS} does not exist. Check if NETCONSOLE_DYNAMIC is enabled" >&2 exit "${ksft_skip}" --- base-commit: 4861333b42178fa3d8fd1bb4e2cfb2fedc968dba change-id: 20241108-netcon_selftest_deps-83f26456f095 Best regards, -- Breno Leitao <leitao(a)debian.org>

11 months

3
2
0 0

[PATCH net-next v9 0/6] Suspend IRQs during application busy periods

by Joe Damato

Greetings: Welcome to v9, see changelog below. This revision addresses feedback Willem gave on the selftests. No functional or code changes to the implementation were made and performance tests were not re-run. This series introduces a new mechanism, IRQ suspension, which allows network applications using epoll to mask IRQs during periods of high traffic while also reducing tail latency (compared to existing mechanisms, see below) during periods of low traffic. In doing so, this balances CPU consumption with network processing efficiency. Martin Karsten (CC'd) and I have been collaborating on this series for several months and have appreciated the feedback from the community on our RFC [1]. We've updated the cover letter and kernel documentation in an attempt to more clearly explain how this mechanism works, how applications can use it, and how it compares to existing mechanisms in the kernel. I briefly mentioned this idea at netdev conf 2024 (for those who were there) and Martin described this idea in an earlier paper presented at Sigmetrics 2024 [2]. ~ The short explanation (TL;DR) We propose adding a new napi config parameter: irq_suspend_timeout to help balance CPU usage and network processing efficiency when using IRQ deferral and napi busy poll. If this parameter is set to a non-zero value *and* a user application has enabled preferred busy poll on a busy poll context (via the EPIOCSPARAMS ioctl introduced in commit 18e2bf0edf4d ("eventpoll: Add epoll ioctl for epoll_params")), then application calls to epoll_wait for that context will cause device IRQs and softirq processing to be suspended as long as epoll_wait successfully retrieves data from the NAPI. Each time data is retrieved, the irq_suspend_timeout is deferred. If/when network traffic subsides and epoll_wait returns no data, IRQ suspension is immediately reverted back to the existing napi_defer_hard_irqs and gro_flush_timeout mechanism which was introduced in commit 6f8b12d661d0 ("net: napi: add hard irqs deferral feature")). The irq_suspend_timeout serves as a safety mechanism. If userland takes a long time processing data, irq_suspend_timeout will fire and restart normal NAPI processing. For a more in depth explanation, please continue reading. ~ Comparison with existing mechanisms Interrupt mitigation can be accomplished in napi software, by setting napi_defer_hard_irqs and gro_flush_timeout, or via interrupt coalescing in the NIC. This can be quite efficient, but in both cases, a fixed timeout (or packet count) needs to be configured. However, a fixed timeout cannot effectively support both low- and high-load situations: At low load, an application typically processes a few requests and then waits to receive more input data. In this scenario, a large timeout will cause unnecessary latency. At high load, an application typically processes many requests before being ready to receive more input data. In this case, a small timeout will likely fire prematurely and trigger irq/softirq processing, which interferes with the application's execution. This causes overhead, most likely due to cache contention. While NICs attempt to provide adaptive interrupt coalescing schemes, these cannot properly take into account application-level processing. An alternative packet delivery mechanism is busy-polling, which results in perfect alignment of application processing and network polling. It delivers optimal performance (throughput and latency), but results in 100% cpu utilization and is thus inefficient for below-capacity workloads. We propose to add a new packet delivery mode that properly alternates between busy polling and interrupt-based delivery depending on busy and idle periods of the application. During a busy period, the system operates in busy-polling mode, which avoids interference. During an idle period, the system falls back to interrupt deferral, but with a small timeout to avoid excessive latencies. This delivery mode can also be viewed as an extension of basic interrupt deferral, but alternating between a small and a very large timeout. This delivery mode is efficient, because it avoids softirq execution interfering with application processing during busy periods. It can be used with blocking epoll_wait to conserve cpu cycles during idle periods. The effect of alternating between busy and idle periods is that performance (throughput and latency) is very close to full busy polling, while cpu utilization is lower and very close to interrupt mitigation. ~ Usage details IRQ suspension is introduced via a per-NAPI configuration parameter that controls the maximum time that IRQs can be suspended. Here's how it is intended to work: - The user application (or system administrator) uses the netdev-genl netlink interface to set the pre-existing napi_defer_hard_irqs and gro_flush_timeout NAPI config parameters to enable IRQ deferral. - The user application (or system administrator) sets the proposed irq_suspend_timeout parameter via the netdev-genl netlink interface to a larger value than gro_flush_timeout to enable IRQ suspension. - The user application issues the existing epoll ioctl to set the prefer_busy_poll flag on the epoll context. - The user application then calls epoll_wait to busy poll for network events, as it normally would. - If epoll_wait returns events to userland, IRQs are suspended for the duration of irq_suspend_timeout. - If epoll_wait finds no events and the thread is about to go to sleep, IRQ handling using napi_defer_hard_irqs and gro_flush_timeout is resumed. As long as epoll_wait is retrieving events, IRQs (and softirq processing) for the NAPI being polled remain disabled. When network traffic reduces, eventually a busy poll loop in the kernel will retrieve no data. When this occurs, regular IRQ deferral using gro_flush_timeout for the polled NAPI is re-enabled. Unless IRQ suspension is continued by subsequent calls to epoll_wait, it automatically times out after the irq_suspend_timeout timer expires. Regular deferral is also immediately re-enabled when the epoll context is destroyed. ~ Usage scenario The target scenario for IRQ suspension as packet delivery mode is a system that runs a dominant application with substantial network I/O. The target application can be configured to receive input data up to a certain batch size (via epoll_wait maxevents parameter) and this batch size determines the worst-case latency that application requests might experience. Because packet delivery is suspended during the target application's processing, the batch size also determines the worst-case latency of concurrent applications using the same RX queue(s). gro_flush_timeout should be set as small as possible, but large enough to make sure that a single request is likely not being interfered with. irq_suspend_timeout is largely a safety mechanism against misbehaving applications. It should be set large enough to cover the processing of an entire application batch, i.e., the factor between gro_flush_timeout and irq_suspend_timeout should roughly correspond to the maximum batch size that the target application would process in one go. ~ Important call out in the implementation - Enabling per epoll-context preferred busy poll will now effectively lead to a nonblocking iteration through napi_busy_loop, even when busy_poll_usecs is 0. See patch 4. ~ Benchmark configs & descriptions The changes were benchmarked with memcached [3] using the benchmarking tool mutilate [4]. To facilitate benchmarking, a small patch [5] was applied to memcached 1.6.29 to allow setting per-epoll context preferred busy poll and other settings via environment variables. Another small patch [6] was applied to libevent to enable full busy-polling. Multiple scenarios were benchmarked as described below and the scripts used for producing these results can be found on github [7] (note: all scenarios use NAPI-based traffic splitting via SO_INCOMING_ID by passing -N to memcached): - base: - no other options enabled - deferX: - set defer_hard_irqs to 100 - set gro_flush_timeout to X,000 - napibusy: - set defer_hard_irqs to 100 - set gro_flush_timeout to 200,000 - enable busy poll via the existing ioctl (busy_poll_usecs = 64, busy_poll_budget = 64, prefer_busy_poll = true) - fullbusy: - set defer_hard_irqs to 100 - set gro_flush_timeout to 5,000,000 - enable busy poll via the existing ioctl (busy_poll_usecs = 1000, busy_poll_budget = 64, prefer_busy_poll = true) - change memcached's nonblocking epoll_wait invocation (via libevent) to using a 1 ms timeout - suspend0: - set defer_hard_irqs to 0 - set gro_flush_timeout to 0 - set irq_suspend_timeout to 20,000,000 - enable busy poll via the existing ioctl (busy_poll_usecs = 0, busy_poll_budget = 64, prefer_busy_poll = true) - suspendX: - set defer_hard_irqs to 100 - set gro_flush_timeout to X,000 - set irq_suspend_timeout to 20,000,000 - enable busy poll via the existing ioctl (busy_poll_usecs = 0, busy_poll_budget = 64, prefer_busy_poll = true) ~ Benchmark results Tested on: Single socket AMD EPYC 7662 64-Core Processor Hyperthreading disabled 4 NUMA Zones (NPS=4) 16 CPUs per NUMA zone (64 cores total) 2 x Dual port 100gbps Mellanox Technologies ConnectX-5 Ex EN NIC The test machine is configured such that a single interface has 8 RX queues. The queues' IRQs and memcached are pinned to CPUs that are NUMA-local to the interface which is under test. The NIC's interrupt coalescing configuration is left at boot-time defaults. Results: Results are shown below. The mechanism added by this series is represented by the 'suspend' cases. Data presented shows a summary over nearly 10 runs of each test case [8] using the scripts on github [7]. For latency, the median is shown. For throughput and CPU utilization, the average is shown. The results also include cycles-per-query (cpq) and instruction-per-query (ipq) metrics, following the methodology proposed in [2], to augment the CPU utilization numbers, which could be skewed due to frequency scaling. We find that this does not appear to be the case as CPU utilization and low-level metrics show similar trends. These results were captured using the scripts on github [7] to illustrate how this approach compares with other pre-existing mechanisms. This data is not to be interpreted as scientific data captured in a fully isolated lab setting, but instead as best effort, illustrative information comparing and contrasting tradeoffs. The absolute QPS results shift between submissions, but the relative differences are equivalent. As patches are rebased, several factors likely influence overall performance. Compare: - Throughput (MAX) and latencies of base vs suspend. - CPU usage of napibusy and fullbusy during lower load (200K, 400K for example) vs suspend. - Latency of the defer variants vs suspend as timeout and load increases. - suspend0, which sets defer_hard_irqs and gro_flush_timeout to 0, has nearly the same performance as the base case (this is FAQ item #1). The overall takeaway is that the suspend variants provide a superior combination of high throughput, low latency, and low cpu utilization compared to all other variants. Each of the suspend variants works very well, but some fine-tuning between latency and cpu utilization is still possible by tuning the small timeout (gro_flush_timeout). Note: we've reorganized the results to make comparison among testcases with the same load easier. testcase load qps avglat 95%lat 99%lat cpu cpq ipq base 200K 199946 112 239 416 26 12973 11343 defer10 200K 199971 54 124 142 29 19412 17460 defer20 200K 199986 60 130 153 26 15644 14095 defer50 200K 200025 79 144 182 23 12122 11632 defer200 200K 199999 164 254 309 19 8923 9635 fullbusy 200K 199998 46 118 133 100 43658 23133 napibusy 200K 199983 100 237 277 56 24840 24716 suspend0 200K 200020 105 249 432 30 14264 11796 suspend10 200K 199950 53 123 141 32 19518 16903 suspend20 200K 200037 58 126 151 30 16426 14736 suspend50 200K 199961 73 136 177 26 13310 12633 suspend200 200K 199998 149 251 306 21 9566 10203 testcase load qps avglat 95%lat 99%lat cpu cpq ipq base 400K 400014 139 269 707 41 9476 9343 defer10 400K 400016 59 133 166 53 13991 12989 defer20 400K 399952 67 140 172 47 12063 11644 defer50 400K 400007 87 162 198 39 9384 9880 defer200 400K 399979 181 274 330 31 7089 8430 fullbusy 400K 399987 50 123 156 100 21827 16037 napibusy 400K 400014 76 222 272 83 18185 16529 suspend0 400K 400015 127 350 776 47 10699 9603 suspend10 400K 400023 57 129 164 54 13758 13178 suspend20 400K 400043 62 135 169 49 12071 11826 suspend50 400K 400071 76 149 186 42 10011 10301 suspend200 400K 399961 154 269 327 34 7827 8774 testcase load qps avglat 95%lat 99%lat cpu cpq ipq base 600K 599951 149 266 574 61 9265 8876 defer10 600K 600006 71 147 203 76 11866 10936 defer20 600K 600123 76 152 203 66 10430 10342 defer50 600K 600162 95 172 217 54 8526 9142 defer200 600K 599942 200 301 357 46 6977 8212 fullbusy 600K 599990 55 127 177 100 14551 13983 napibusy 600K 600035 63 160 250 96 13937 14140 suspend0 600K 599903 127 320 732 68 10166 8963 suspend10 600K 599908 63 137 192 69 10902 11100 suspend20 600K 599961 66 141 194 65 9976 10370 suspend50 600K 599973 80 159 204 57 8678 9381 suspend200 600K 600010 157 277 346 48 7133 8381 testcase load qps avglat 95%lat 99%lat cpu cpq ipq base 800K 800039 181 300 536 87 9585 8304 defer10 800K 800038 181 530 939 96 10564 8970 defer20 800K 800029 112 225 329 90 10056 8935 defer50 800K 799999 120 208 296 82 9234 8562 defer200 800K 800066 227 338 401 63 7117 8129 fullbusy 800K 800040 61 134 190 100 10913 12608 napibusy 800K 799944 64 141 214 99 10828 12588 suspend0 800K 799911 126 248 509 85 9346 8498 suspend10 800K 800006 69 143 200 83 9410 9845 suspend20 800K 800120 74 150 207 78 8786 9454 suspend50 800K 799989 87 168 224 71 7946 8833 suspend200 800K 799987 160 292 357 62 6923 8229 testcase load qps avglat 95%lat 99%lat cpu cpq ipq base 1000K 906879 4079 5751 6216 98 9496 7904 defer10 1000K 860849 3643 6274 6730 99 10040 8676 defer20 1000K 896063 3298 5840 6349 98 9620 8237 defer50 1000K 919782 2962 5513 5807 97 9284 7951 defer200 1000K 970941 3059 5348 5984 95 8593 7959 fullbusy 1000K 999950 70 150 207 100 8732 10777 napibusy 1000K 999996 78 154 223 100 8722 10656 suspend0 1000K 949706 2666 5770 6660 99 9071 8046 suspend10 1000K 1000024 80 160 220 92 8137 9035 suspend20 1000K 1000059 83 165 226 89 7850 8804 suspend50 1000K 999955 95 180 240 84 7411 8459 suspend200 1000K 999914 163 299 366 77 6833 8078 testcase load qps avglat 95%lat 99%lat cpu cpq ipq base MAX 1037654 4184 5453 5810 100 8411 7938 defer10 MAX 905607 4840 6151 6380 100 9639 8431 defer20 MAX 986463 4455 5594 5796 100 8848 8110 defer50 MAX 1077030 4000 5073 5299 100 8104 7920 defer200 MAX 1040728 4152 5385 5765 100 8379 7849 fullbusy MAX 1247536 3518 3935 3984 100 6998 7930 napibusy MAX 1136310 3799 7756 9964 100 7670 7877 suspend0 MAX 1057509 4132 5724 6185 100 8253 7918 suspend10 MAX 1215147 3580 3957 4041 100 7185 7944 suspend20 MAX 1216469 3576 3953 3988 100 7175 7950 suspend50 MAX 1215871 3577 3961 4075 100 7181 7949 suspend200 MAX 1216882 3556 3951 3988 100 7175 7955 ~ FAQ - Why is a new parameter needed? Does irq_suspend_timeout override gro_flush_timeout? Using the suspend mechanism causes the system to alternate between polling mode and irq-driven packet delivery. During busy periods, irq_suspend_timeout overrides gro_flush_timeout and keeps the system busy polling, but when epoll finds no events, the setting of gro_flush_timeout and napi_defer_hard_irqs determine the next step. There are essentially three possible loops for network processing and packet delivery: 1) hardirq -> softirq -> napi poll; basic interrupt delivery 2) timer -> softirq -> napi poll; deferred irq processing 3) epoll -> busy-poll -> napi poll; busy looping Loop 2 can take control from Loop 1, if gro_flush_timeout and napi_defer_hard_irqs are set. If gro_flush_timeout and napi_defer_hard_irqs are set, Loops 2 and 3 "wrestle" with each other for control. During busy periods, irq_suspend_timeout is used as timer in Loop 2, which essentially tilts this in favour of Loop 3. If gro_flush_timeout and napi_defer_hard_irqs are not set, Loop 3 cannot take control from Loop 1. Therefore, setting gro_flush_timeout and napi_defer_hard_irqs is the recommended usage, because otherwise setting irq_suspend_timeout might not have any discernible effect. This is shown in the results above: compare suspend0 with the base case. Note that the lack of napi_defer_hard_irqs and gro_flush_timeout produce similar results for both, which encourages the use of napi_defer_hard_irqs and gro_flush_timeout in addition to irq_suspend_timeout. - Can the new timeout value be threaded through the new epoll ioctl ? It is possible, but presents challenges for userspace. User applications must ensure that the file descriptors added to epoll contexts have the same NAPI ID to support busy polling. An epoll context is not permanently tied to any particular NAPI ID. So, a user application could decide to clear the file descriptors from the context and add a new set of file descriptors with a different NAPI ID to the context. Busy polling would work as expected, but the meaning of the suspend timeout becomes ambiguous because IRQs are not inherently associated with epoll contexts, but rather with the NAPI. The user program would need to reissue the ioctl to set the irq_suspend_timeout, but the napi_defer_hard_irqs and gro_flush_timeout settings would come from the NAPI's napi_config (which are set either by sysfs or by netlink). Such an interface seems awkard to use from a user perspective. Further, IRQs are related to NAPIs, which is why they are stored in the napi_config space. Putting the irq_suspend_timeout in the epoll context while other IRQ deferral mechanisms remain in the NAPI's napi_config space seems like an odd design choice. We've opted to keep all of the IRQ deferral parameters together and place the irq_suspend_timeout in napi_config. This has nice benefits for userspace: if a user app were to remove all file descriptors from an epoll context and add new file descriptors with a new NAPI ID, the correct suspend timeout for that NAPI ID would be used automatically without the user application needing to do anything (like re-issuing an ioctl, for example). All IRQ deferral related parameters are in one place and can all be set the same way: with netlink. - Can irq suspend be built by combining NIC coalescing and gro_flush_timeout ? No. The problem is that the long timeout must engage if and only if prefer-busy is active. When using NIC coalescing for the short timeout (without napi_defer_hard_irqs/gro_flush_timeout), an interrupt after an idle period will trigger softirq, which will run napi polling. At this point, prefer-busy is not active, so NIC interrupts would be re-enabled. Then it is not possible for the longer timeout to interject to switch control back to polling. In other words, only by using the software timer for the short timeout, it is possible to extend the timeout without having to reprogram the NIC timer or reach down directly and disable interrupts. Using gro_flush_timeout for the long timeout also has problems, for the same underlying reason. In the current napi implementation, gro_flush_timeout is not tied to prefer-busy. We'd either have to change that and in the process modify the existing deferral mechanism, or introduce a state variable to determine whether gro_flush_timeout is used as long timeout for irq suspend or whether it is used for its default purpose. In an earlier version, we did try something similar to the latter and made it work, but it ends up being a lot more convoluted than our current proposal. - Isn't it already possible to combine busy looping with irq deferral? Yes, in fact enabling irq deferral via napi_defer_hard_irqs and gro_flush_timeout is a precondition for prefer_busy_poll to have an effect. If the application also uses a tight busy loop with essentially nonblocking epoll_wait (accomplished with a very short timeout parameter), this is the fullbusy case shown in the results. An application using blocking epoll_wait is shown as the napibusy case in the results. It's a hybrid approach that provides limited latency benefits compared to the base case and plain irq deferral, but not as good as fullbusy or suspend. ~ Special thanks Several people were involved in earlier stages of the development of this mechanism whom we'd like to thank: - Peter Cai (CC'd), for the initial kernel patch and his contributions to the paper. - Mohammadamin Shafie (CC'd), for testing various versions of the kernel patch and providing helpful feedback. Thanks, Martin and Joe [1]: https://lore.kernel.org/netdev/20240812125717.413108-1-jdamato@fastly.com/ [2]: https://doi.org/10.1145/3626780 [3]: https://github.com/memcached/memcached/blob/master/doc/napi_ids.txt [4]: https://github.com/leverich/mutilate [5]: https://raw.githubusercontent.com/martinkarsten/irqsuspend/main/patches/mem… [6]: https://raw.githubusercontent.com/martinkarsten/irqsuspend/main/patches/lib… [7]: https://github.com/martinkarsten/irqsuspend [8]: https://github.com/martinkarsten/irqsuspend/tree/main/results v9: - Addresses Willem's feedback on the selftests in patch 5 by fixing the SPDX-License-Identifier, moving constants into variables in the test script, reducing code duplication, shortening long lines, and renaming variables to be more reader friendly. In the C test file, added a comment explaining the if def blob and changed a few types for strtoul. v8: https://lore.kernel.org/netdev/20241108045337.292905-1-jdamato@fastly.com/ - Update patch 2 to drop the exports, as requested by Jakub. v7: https://lore.kernel.org/netdev/20241108023912.98416-1-jdamato@fastly.com/ - Jakub noted that patch 2 adds unnecessary complexity by checking the suspend timeout in the NAPI loop. This makes the code more complicated and difficult to reason about. He's right; we've dropped patch 2 which simplifies this series. - Updated the cover letter with a full re-run of all test cases. - Updated FAQ #2. v6: https://lore.kernel.org/netdev/20241104215542.215919-1-jdamato@fastly.com/ - Updated the cover letter with a full re-run of all test cases, including a new case suspend0, as requested by Sridhar previously. - Updated the kernel documentation in patch 7 as suggested by Bagas Sanjaya, which improved the htmldoc output. v5: https://lore.kernel.org/netdev/20241103052421.518856-1-jdamato@fastly.com/ - Adjusted patch 5 to only suspend IRQs when ep_send_events returns a positive return value. This issue was pointed out by Hillf Danton. - Updated the commit message of patch 6 which still mentioned netcat, despite the code being updated in v4 to replace it with socat and fixed misspelling of netdevsim. - Fixed a minor typo in patch 7 and removed an unnecessary paragraph. - Added Sridhar Samudrala's Reviewed-by to patch 1-5 and 7. v4: https://lore.kernel.org/netdev/20241102005214.32443-1-jdamato@fastly.com/ - Added a new FAQ item to cover letter. - Updated patch 6 to use socat instead of nc in busy_poll_test.sh and updated busy_poller.c to use netlink directly to configure napi params. - Updated the kernel documentation in patch 7 to include more details. - Dropped Stanislav's Acked-by and Bagas' Reviewed-by from patch 7 since the documentation was updated. v3: https://lore.kernel.org/netdev/20241101004846.32532-1-jdamato@fastly.com/ - Added Stanislav Fomichev's Acked-by to every patch except the newly added selftest. - Added Bagas Sanjaya's Reviewed-by to the documentation patch. - Fixed the commit message of patch 2 to remove a reference to the now non-existent sysfs setting. - Added a self test which tests both "regular" busy poll and busy poll with suspend enabled. This was added as patch 6 as requested by Paolo. netdevsim was chosen instead of veth due to netdevsim's pre-existing support for netdev-genl. See the commit message of patch 6 for more details. v2: https://lore.kernel.org/bpf/20241021015311.95468-1-jdamato@fastly.com/ - Cover letter updated, including a re-run of test data. - Patch 1 rewritten to use netdev-genl instead of sysfs. - Patch 3 updated with a comment added to napi_resume_irqs. - Patch 4 rebased to apply now that commit b9ca079dd6b0 ("eventpoll: Annotate data-race of busy_poll_usecs") has been picked up from VFS. - Patch 6 updated the kernel documentation. rfc -> v1: - Cover letter updated to include more details. - Patch 1 updated to remove the documentation added. This was moved to patch 6 with the rest of the docs (see below). - Patch 5 updated to fix an error uncovered by the kernel build robot. See patch 5's changelog for more details. - Patch 6 added which updates kernel documentation. Joe Damato (2): selftests: net: Add busy_poll_test docs: networking: Describe irq suspension Martin Karsten (4): net: Add napi_struct parameter irq_suspend_timeout net: Add control functions for irq suspension eventpoll: Trigger napi_busy_loop, if prefer_busy_poll is set eventpoll: Control irq suspension for prefer_busy_poll Documentation/netlink/specs/netdev.yaml | 7 + Documentation/networking/napi.rst | 170 ++++++++- fs/eventpoll.c | 36 +- include/linux/netdevice.h | 2 + include/net/busy_poll.h | 3 + include/uapi/linux/netdev.h | 1 + net/core/dev.c | 39 ++ net/core/dev.h | 25 ++ net/core/netdev-genl-gen.c | 5 +- net/core/netdev-genl.c | 12 + tools/include/uapi/linux/netdev.h | 1 + tools/testing/selftests/net/.gitignore | 1 + tools/testing/selftests/net/Makefile | 3 +- tools/testing/selftests/net/busy_poll_test.sh | 165 +++++++++ tools/testing/selftests/net/busy_poller.c | 346 ++++++++++++++++++ 15 files changed, 809 insertions(+), 7 deletions(-) create mode 100755 tools/testing/selftests/net/busy_poll_test.sh create mode 100644 tools/testing/selftests/net/busy_poller.c base-commit: dc7c381bb8649e3701ed64f6c3e55316675904d7 -- 2.25.1

11 months

3
3
0 0

[PATCH net-next v8 00/12] selftests: ncdevmem: Add ncdevmem to ksft

by Stanislav Fomichev

The goal of the series is to simplify and make it possible to use ncdevmem in an automated way from the ksft python wrapper. ncdevmem is slowly mutated into a state where it uses stdout to print the payload and the python wrapper is added to make sure the arrived payload matches the expected one. v8: - move error() calls into enable_reuseaddr() (Joe) - bail out when number of queues is 1 (Joe) - use socat instead of nc (Joe) - fix warning about string truncation buf[256]->buf[40] (Jakub) v7: - fix validation (Mina) - add support for working with non ::ffff-prefixed addresses (Mina) v6: - fix compilation issue in 'Unify error handling' patch (Jakub) v5: - properly handle errors from inet_pton() and socket() (Paolo) - remove unneeded import from python selftest (Paolo) v4: - keep usage example with validation (Mina) - fix compilation issue in one patch (s/start_queues/start_queue/) v3: - keep and refine the comment about ncdevmem invocation (Mina) - add the comment about not enforcing exit status for ntuple reset (Mina) - make configure_headersplit more robust (Mina) - use num_queues/2 in selftest and let the users override it (Mina) - remove memory_provider.memcpy_to_device (Mina) - keep ksft as is (don't use -v validate flags): we are gonna need a --debug-disable flag to make it less chatty; otherwise it times out when sending too much data; so leaving it as a separate follow up v2: - don't remove validation (Mina) - keep 5-tuple flow steering but use it only when -c is provided (Mina) - remove separate flag for probing (Mina) - move ncdevmem under drivers/net/hw, not drivers/net (Jakub) Cc: Mina Almasry <almasrymina(a)google.com> Stanislav Fomichev (12): selftests: ncdevmem: Redirect all non-payload output to stderr selftests: ncdevmem: Separate out dmabuf provider selftests: ncdevmem: Unify error handling selftests: ncdevmem: Make client_ip optional selftests: ncdevmem: Remove default arguments selftests: ncdevmem: Switch to AF_INET6 selftests: ncdevmem: Properly reset flow steering selftests: ncdevmem: Use YNL to enable TCP header split selftests: ncdevmem: Remove hard-coded queue numbers selftests: ncdevmem: Run selftest when none of the -s or -c has been provided selftests: ncdevmem: Move ncdevmem under drivers/net/hw selftests: ncdevmem: Add automated test .../selftests/drivers/net/hw/.gitignore | 1 + .../testing/selftests/drivers/net/hw/Makefile | 9 + .../selftests/drivers/net/hw/devmem.py | 45 + .../selftests/drivers/net/hw/ncdevmem.c | 789 ++++++++++++++++++ tools/testing/selftests/net/.gitignore | 1 - tools/testing/selftests/net/Makefile | 8 - tools/testing/selftests/net/ncdevmem.c | 570 ------------- 7 files changed, 844 insertions(+), 579 deletions(-) create mode 100644 tools/testing/selftests/drivers/net/hw/.gitignore create mode 100755 tools/testing/selftests/drivers/net/hw/devmem.py create mode 100644 tools/testing/selftests/drivers/net/hw/ncdevmem.c delete mode 100644 tools/testing/selftests/net/ncdevmem.c -- 2.47.0

11 months

4
16
0 0

[PATCH net-next v3 0/4] Introduce VLAN support in HSR

by MD Danish Anwar

This series adds VLAN support to HSR framework. This series also adds VLAN support to HSR mode of ICSSG Ethernet driver. Changes from v2 to v3: *) Modified hsr_ndo_vlan_rx_add_vid() to handle arbitrary HSR_PT_SLAVE_A, HSR_PT_SLAVE_B order and skip INTERLINK port in patch 2/4 as suggested by Paolo Abeni <pabeni(a)redhat.com> *) Removed handling of HSR_PT_MASTER in hsr_ndo_vlan_rx_kill_vid() as MASTER and INTERLINK port will be ignored anyway in the default switch case as suggested by Paolo Abeni <pabeni(a)redhat.com> *) Modified the selftest in patch 4/4 to use vlan by default. The test will check the exposed feature `vlan-challenged` and if vlan is not supported, skip the vlan test as suggested by Paolo Abeni <pabeni(a)redhat.com>. Test logs can be found at [1] Changes from v1 to v2: *) Added patch 4/4 to add test script related to VLAN in HSR as asked by Lukasz Majewski <lukma(a)denx.de> [1] https://gist.githubusercontent.com/danish-ti/d309f92c640134ccc4f2c0c442de5b… v1 https://lore.kernel.org/all/20241004074715.791191-1-danishanwar@ti.com/ v2 https://lore.kernel.org/all/20241024103056.3201071-1-danishanwar@ti.com/ MD Danish Anwar (1): selftests: hsr: Add test for VLAN Murali Karicheri (1): net: hsr: Add VLAN CTAG filter support Ravi Gunasekaran (1): net: ti: icssg-prueth: Add VLAN support for HSR mode WingMan Kwok (1): net: hsr: Add VLAN support drivers/net/ethernet/ti/icssg/icssg_prueth.c | 45 ++++++++- net/hsr/hsr_device.c | 85 +++++++++++++++-- net/hsr/hsr_forward.c | 19 +++- tools/testing/selftests/net/hsr/config | 1 + tools/testing/selftests/net/hsr/hsr_ping.sh | 98 ++++++++++++++++++++ 5 files changed, 236 insertions(+), 12 deletions(-) base-commit: a84e8c05f58305dfa808bc5465c5175c29d7c9b6 -- 2.34.1

11 months

3
6
0 0

[PATCH net-next v7] ipv6: Fix soft lockups in fib6_select_path under high next hop churn

by Omid Ehtemam-Haghighi

Soft lockups have been observed on a cluster of Linux-based edge routers located in a highly dynamic environment. Using the `bird` service, these routers continuously update BGP-advertised routes due to frequently changing nexthop destinations, while also managing significant IPv6 traffic. The lockups occur during the traversal of the multipath circular linked-list in the `fib6_select_path` function, particularly while iterating through the siblings in the list. The issue typically arises when the nodes of the linked list are unexpectedly deleted concurrently on a different core—indicated by their 'next' and 'previous' elements pointing back to the node itself and their reference count dropping to zero. This results in an infinite loop, leading to a soft lockup that triggers a system panic via the watchdog timer. Apply RCU primitives in the problematic code sections to resolve the issue. Where necessary, update the references to fib6_siblings to annotate or use the RCU APIs. Include a test script that reproduces the issue. The script periodically updates the routing table while generating a heavy load of outgoing IPv6 traffic through multiple iperf3 clients. It consistently induces infinite soft lockups within a couple of minutes. Kernel log: 0 [ffffbd13003e8d30] machine_kexec at ffffffff8ceaf3eb 1 [ffffbd13003e8d90] __crash_kexec at ffffffff8d0120e3 2 [ffffbd13003e8e58] panic at ffffffff8cef65d4 3 [ffffbd13003e8ed8] watchdog_timer_fn at ffffffff8d05cb03 4 [ffffbd13003e8f08] __hrtimer_run_queues at ffffffff8cfec62f 5 [ffffbd13003e8f70] hrtimer_interrupt at ffffffff8cfed756 6 [ffffbd13003e8fd0] __sysvec_apic_timer_interrupt at ffffffff8cea01af 7 [ffffbd13003e8ff0] sysvec_apic_timer_interrupt at ffffffff8df1b83d -- <IRQ stack> -- 8 [ffffbd13003d3708] asm_sysvec_apic_timer_interrupt at ffffffff8e000ecb [exception RIP: fib6_select_path+299] RIP: ffffffff8ddafe7b RSP: ffffbd13003d37b8 RFLAGS: 00000287 RAX: ffff975850b43600 RBX: ffff975850b40200 RCX: 0000000000000000 RDX: 000000003fffffff RSI: 0000000051d383e4 RDI: ffff975850b43618 RBP: ffffbd13003d3800 R8: 0000000000000000 R9: ffff975850b40200 R10: 0000000000000000 R11: 0000000000000000 R12: ffffbd13003d3830 R13: ffff975850b436a8 R14: ffff975850b43600 R15: 0000000000000007 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 9 [ffffbd13003d3808] ip6_pol_route at ffffffff8ddb030c 10 [ffffbd13003d3888] ip6_pol_route_input at ffffffff8ddb068c 11 [ffffbd13003d3898] fib6_rule_lookup at ffffffff8ddf02b5 12 [ffffbd13003d3928] ip6_route_input at ffffffff8ddb0f47 13 [ffffbd13003d3a18] ip6_rcv_finish_core.constprop.0 at ffffffff8dd950d0 14 [ffffbd13003d3a30] ip6_list_rcv_finish.constprop.0 at ffffffff8dd96274 15 [ffffbd13003d3a98] ip6_sublist_rcv at ffffffff8dd96474 16 [ffffbd13003d3af8] ipv6_list_rcv at ffffffff8dd96615 17 [ffffbd13003d3b60] __netif_receive_skb_list_core at ffffffff8dc16fec 18 [ffffbd13003d3be0] netif_receive_skb_list_internal at ffffffff8dc176b3 19 [ffffbd13003d3c50] napi_gro_receive at ffffffff8dc565b9 20 [ffffbd13003d3c80] ice_receive_skb at ffffffffc087e4f5 [ice] 21 [ffffbd13003d3c90] ice_clean_rx_irq at ffffffffc0881b80 [ice] 22 [ffffbd13003d3d20] ice_napi_poll at ffffffffc088232f [ice] 23 [ffffbd13003d3d80] __napi_poll at ffffffff8dc18000 24 [ffffbd13003d3db8] net_rx_action at ffffffff8dc18581 25 [ffffbd13003d3e40] __do_softirq at ffffffff8df352e9 26 [ffffbd13003d3eb0] run_ksoftirqd at ffffffff8ceffe47 27 [ffffbd13003d3ec0] smpboot_thread_fn at ffffffff8cf36a30 28 [ffffbd13003d3ee8] kthread at ffffffff8cf2b39f 29 [ffffbd13003d3f28] ret_from_fork at ffffffff8ce5fa64 30 [ffffbd13003d3f50] ret_from_fork_asm at ffffffff8ce03cbb Fixes: 66f5d6ce53e6 ("ipv6: replace rwlock with rcu and spinlock in fib6_table") Reported-by: Adrian Oliver <kernel(a)aoliver.ca> Signed-off-by: Omid Ehtemam-Haghighi <omid.ehtemamhaghighi(a)menlosecurity.com> Cc: David S. Miller <davem(a)davemloft.net> Cc: David Ahern <dsahern(a)gmail.com> Cc: Eric Dumazet <edumazet(a)google.com> Cc: Jakub Kicinski <kuba(a)kernel.org> Cc: Paolo Abeni <pabeni(a)redhat.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Ido Schimmel <idosch(a)idosch.org> Cc: Kuniyuki Iwashima <kuniyu(a)amazon.com> Cc: Simon Horman <horms(a)kernel.org> Cc: Omid Ehtemam-Haghighi <oeh.kernel(a)gmail.com> Cc: netdev(a)vger.kernel.org Cc: linux-kselftest(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org --- v6 -> v7: * Rebased on top of 'net-next' v5 -> v6: * Adjust the comment line lengths in the test script to a maximum of 80 characters * Change memory allocation in inet6_rt_notify from gfp_any() to GFP_ATOMIC for atomic allocation in non-blocking contexts, as suggested by Ido Schimmel * NOTE: I have executed the test script on both bare-metal servers and virtualized environments such as QEMU and vng. In the case of bare-metal, it consistently triggers a soft lockup in under a minute on unpatched kernels. For the virtualized environments, an unpatched kernel compiled with the Ubuntu 24.04 configuration also triggers a soft lockup, though it takes longer; however, it did not trigger a soft lockup on kernels compiled with configurations provided in: https://github.com/linux-netdev/nipa/wiki/How-to-run-netdev-selftests-CI-st… leading to potential false negatives in the test results. I am curious if this test can be executed on a bare-metal machine within a CI system, if such a setup exists, rather than in a virtualized environment. If that’s not possible, how can I apply a different kernel configuration, such as the one used in Ubuntu 24.04, for this test? Please advise. v4 -> v5: * Addressed review comments from Paolo Abeni. * Added additional clarifying comments in the test script. * Minor cleanup performed in the test script. v3 -> v4: * Added RCU primitives to rt6_fill_node(). I found that this function is typically called either with a table lock held or within rcu_read_lock/rcu_read_unlock pairs, except in the following call chain, where the protection is unclear: rt_fill_node() fib6_info_hw_flags_set() mlxsw_sp_fib6_offload_failed_flag_set() mlxsw_sp_router_fib6_event_work() The last function is initialized as a work item in mlxsw_sp_router_fib_event() and scheduled for deferred execution. I am unsure if the execution context of this work item is protected by any table lock or rcu_read_lock/rcu_read_unlock pair, so I have added the protection. Please let me know if this is redundant. * Other review comments addressed v2 -> v3: * Removed redundant rcu_read_lock()/rcu_read_unlock() pairs * Revised the test script based on Ido Schimmel's feedback * Updated the test script to ensure compatibility with the latest iperf3 version * Fixed new warnings generated with 'C=2' in the previous version * Other review comments addressed v1 -> v2: * list_del_rcu() is applied exclusively to legacy multipath code * All occurrences of fib6_siblings have been modified to utilize RCU APIs for annotation and usage. * Additionally, a test script for reproducing the reported issue is included --- net/ipv6/ip6_fib.c | 8 +- net/ipv6/route.c | 45 ++- tools/testing/selftests/net/Makefile | 1 + .../net/ipv6_route_update_soft_lockup.sh | 262 ++++++++++++++++++ 4 files changed, 297 insertions(+), 19 deletions(-) create mode 100755 tools/testing/selftests/net/ipv6_route_update_soft_lockup.sh diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c index 6383263bfd04..c134ba202c4c 100644 --- a/net/ipv6/ip6_fib.c +++ b/net/ipv6/ip6_fib.c @@ -1183,8 +1183,8 @@ static int fib6_add_rt2node(struct fib6_node *fn, struct fib6_info *rt, while (sibling) { if (sibling->fib6_metric == rt->fib6_metric && rt6_qualify_for_ecmp(sibling)) { - list_add_tail(&rt->fib6_siblings, - &sibling->fib6_siblings); + list_add_tail_rcu(&rt->fib6_siblings, + &sibling->fib6_siblings); break; } sibling = rcu_dereference_protected(sibling->fib6_next, @@ -1245,7 +1245,7 @@ static int fib6_add_rt2node(struct fib6_node *fn, struct fib6_info *rt, fib6_siblings) sibling->fib6_nsiblings--; rt->fib6_nsiblings = 0; - list_del_init(&rt->fib6_siblings); + list_del_rcu(&rt->fib6_siblings); rt6_multipath_rebalance(next_sibling); return err; } @@ -1963,7 +1963,7 @@ static void fib6_del_route(struct fib6_table *table, struct fib6_node *fn, &rt->fib6_siblings, fib6_siblings) sibling->fib6_nsiblings--; rt->fib6_nsiblings = 0; - list_del_init(&rt->fib6_siblings); + list_del_rcu(&rt->fib6_siblings); rt6_multipath_rebalance(next_sibling); } diff --git a/net/ipv6/route.c b/net/ipv6/route.c index d7ce5cf2017a..e23e653de158 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -413,8 +413,8 @@ void fib6_select_path(const struct net *net, struct fib6_result *res, struct flowi6 *fl6, int oif, bool have_oif_match, const struct sk_buff *skb, int strict) { - struct fib6_info *sibling, *next_sibling; struct fib6_info *match = res->f6i; + struct fib6_info *sibling; if (!match->nh && (!match->fib6_nsiblings || have_oif_match)) goto out; @@ -440,8 +440,8 @@ void fib6_select_path(const struct net *net, struct fib6_result *res, if (fl6->mp_hash <= atomic_read(&match->fib6_nh->fib_nh_upper_bound)) goto out; - list_for_each_entry_safe(sibling, next_sibling, &match->fib6_siblings, - fib6_siblings) { + list_for_each_entry_rcu(sibling, &match->fib6_siblings, + fib6_siblings) { const struct fib6_nh *nh = sibling->fib6_nh; int nh_upper_bound; @@ -5195,14 +5195,18 @@ static void ip6_route_mpath_notify(struct fib6_info *rt, * nexthop. Since sibling routes are always added at the end of * the list, find the first sibling of the last route appended */ + rcu_read_lock(); + if ((nlflags & NLM_F_APPEND) && rt_last && rt_last->fib6_nsiblings) { - rt = list_first_entry(&rt_last->fib6_siblings, - struct fib6_info, - fib6_siblings); + rt = list_first_or_null_rcu(&rt_last->fib6_siblings, + struct fib6_info, + fib6_siblings); } if (rt) inet6_rt_notify(RTM_NEWROUTE, rt, info, nlflags); + + rcu_read_unlock(); } static bool ip6_route_mpath_should_notify(const struct fib6_info *rt) @@ -5547,17 +5551,21 @@ static size_t rt6_nlmsg_size(struct fib6_info *f6i) nexthop_for_each_fib6_nh(f6i->nh, rt6_nh_nlmsg_size, &nexthop_len); } else { - struct fib6_info *sibling, *next_sibling; struct fib6_nh *nh = f6i->fib6_nh; + struct fib6_info *sibling; nexthop_len = 0; if (f6i->fib6_nsiblings) { rt6_nh_nlmsg_size(nh, &nexthop_len); - list_for_each_entry_safe(sibling, next_sibling, - &f6i->fib6_siblings, fib6_siblings) { + rcu_read_lock(); + + list_for_each_entry_rcu(sibling, &f6i->fib6_siblings, + fib6_siblings) { rt6_nh_nlmsg_size(sibling->fib6_nh, &nexthop_len); } + + rcu_read_unlock(); } nexthop_len += lwtunnel_get_encap_size(nh->fib_nh_lws); } @@ -5721,7 +5729,7 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb, lwtunnel_fill_encap(skb, dst->lwtstate, RTA_ENCAP, RTA_ENCAP_TYPE) < 0) goto nla_put_failure; } else if (rt->fib6_nsiblings) { - struct fib6_info *sibling, *next_sibling; + struct fib6_info *sibling; struct nlattr *mp; mp = nla_nest_start_noflag(skb, RTA_MULTIPATH); @@ -5733,14 +5741,21 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb, 0) < 0) goto nla_put_failure; - list_for_each_entry_safe(sibling, next_sibling, - &rt->fib6_siblings, fib6_siblings) { + rcu_read_lock(); + + list_for_each_entry_rcu(sibling, &rt->fib6_siblings, + fib6_siblings) { if (fib_add_nexthop(skb, &sibling->fib6_nh->nh_common, sibling->fib6_nh->fib_nh_weight, - AF_INET6, 0) < 0) + AF_INET6, 0) < 0) { + rcu_read_unlock(); + goto nla_put_failure; + } } + rcu_read_unlock(); + nla_nest_end(skb, mp); } else if (rt->nh) { if (nla_put_u32(skb, RTA_NH_ID, rt->nh->id)) @@ -6177,7 +6192,7 @@ void inet6_rt_notify(int event, struct fib6_info *rt, struct nl_info *info, err = -ENOBUFS; seq = info->nlh ? info->nlh->nlmsg_seq : 0; - skb = nlmsg_new(rt6_nlmsg_size(rt), gfp_any()); + skb = nlmsg_new(rt6_nlmsg_size(rt), GFP_ATOMIC); if (!skb) goto errout; @@ -6190,7 +6205,7 @@ void inet6_rt_notify(int event, struct fib6_info *rt, struct nl_info *info, goto errout; } rtnl_notify(skb, net, info->portid, RTNLGRP_IPV6_ROUTE, - info->nlh, gfp_any()); + info->nlh, GFP_ATOMIC); return; errout: rtnl_set_sk_err(net, RTNLGRP_IPV6_ROUTE, err); diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile index 26a4883a65c9..8c4db5199a42 100644 --- a/tools/testing/selftests/net/Makefile +++ b/tools/testing/selftests/net/Makefile @@ -96,6 +96,7 @@ TEST_PROGS += fdb_flush.sh TEST_PROGS += fq_band_pktlimit.sh TEST_PROGS += vlan_hw_filter.sh TEST_PROGS += bpf_offload.py +TEST_PROGS += ipv6_route_update_soft_lockup.sh # YNL files, must be before "include ..lib.mk" YNL_GEN_FILES := ncdevmem diff --git a/tools/testing/selftests/net/ipv6_route_update_soft_lockup.sh b/tools/testing/selftests/net/ipv6_route_update_soft_lockup.sh new file mode 100755 index 000000000000..a6b2b1f9c641 --- /dev/null +++ b/tools/testing/selftests/net/ipv6_route_update_soft_lockup.sh @@ -0,0 +1,262 @@ +#!/bin/bash +# SPDX-License-Identifier: GPL-2.0 +# +# Testing for potential kernel soft lockup during IPv6 routing table +# refresh under heavy outgoing IPv6 traffic. If a kernel soft lockup +# occurs, a kernel panic will be triggered to prevent associated issues. +# +# +# Test Environment Layout +# +# ┌----------------┐ ┌----------------┐ +# | SOURCE_NS | | SINK_NS | +# | NAMESPACE | | NAMESPACE | +# |(iperf3 clients)| |(iperf3 servers)| +# | | | | +# | | | | +# | ┌-----------| nexthops |---------┐ | +# | |veth_source|<--------------------------------------->|veth_sink|<┐ | +# | └-----------|2001:0DB8:1::0:1/96 2001:0DB8:1::1:1/96 |---------┘ | | +# | | ^ 2001:0DB8:1::1:2/96 | | | +# | | . . | fwd | | +# | ┌---------┐ | . . | | | +# | | IPv6 | | . . | V | +# | | routing | | . 2001:0DB8:1::1:80/96| ┌-----┐ | +# | | table | | . | | lo | | +# | | nexthop | | . └--------┴-----┴-┘ +# | | update | | ............................> 2001:0DB8:2::1:1/128 +# | └-------- ┘ | +# └----------------┘ +# +# The test script sets up two network namespaces, source_ns and sink_ns, +# connected via a veth link. Within source_ns, it continuously updates the +# IPv6 routing table by flushing and inserting IPV6_NEXTHOP_ADDR_COUNT nexthop +# IPs destined for SINK_LOOPBACK_IP_ADDR in sink_ns. This refresh occurs at a +# rate of 1/ROUTING_TABLE_REFRESH_PERIOD per second for TEST_DURATION seconds. +# +# Simultaneously, multiple iperf3 clients within source_ns generate heavy +# outgoing IPv6 traffic. Each client is assigned a unique port number starting +# at 5000 and incrementing sequentially. Each client targets a unique iperf3 +# server running in sink_ns, connected to the SINK_LOOPBACK_IFACE interface +# using the same port number. +# +# The number of iperf3 servers and clients is set to half of the total +# available cores on each machine. +# +# NOTE: We have tested this script on machines with various CPU specifications, +# ranging from lower to higher performance as listed below. The test script +# effectively triggered a kernel soft lockup on machines running an unpatched +# kernel in under a minute: +# +# - 1x Intel Xeon E-2278G 8-Core Processor @ 3.40GHz +# - 1x Intel Xeon E-2378G Processor 8-Core @ 2.80GHz +# - 1x AMD EPYC 7401P 24-Core Processor @ 2.00GHz +# - 1x AMD EPYC 7402P 24-Core Processor @ 2.80GHz +# - 2x Intel Xeon Gold 5120 14-Core Processor @ 2.20GHz +# - 1x Ampere Altra Q80-30 80-Core Processor @ 3.00GHz +# - 2x Intel Xeon Gold 5120 14-Core Processor @ 2.20GHz +# - 2x Intel Xeon Silver 4214 24-Core Processor @ 2.20GHz +# - 1x AMD EPYC 7502P 32-Core @ 2.50GHz +# - 1x Intel Xeon Gold 6314U 32-Core Processor @ 2.30GHz +# - 2x Intel Xeon Gold 6338 32-Core Processor @ 2.00GHz +# +# On less performant machines, you may need to increase the TEST_DURATION +# parameter to enhance the likelihood of encountering a race condition leading +# to a kernel soft lockup and avoid a false negative result. +# +# NOTE: The test may not produce the expected result in virtualized +# environments (e.g., qemu) due to differences in timing and CPU handling, +# which can affect the conditions needed to trigger a soft lockup. + +source lib.sh +source net_helper.sh + +TEST_DURATION=300 +ROUTING_TABLE_REFRESH_PERIOD=0.01 + +IPERF3_BITRATE="300m" + + +IPV6_NEXTHOP_ADDR_COUNT="128" +IPV6_NEXTHOP_ADDR_MASK="96" +IPV6_NEXTHOP_PREFIX="2001:0DB8:1" + + +SOURCE_TEST_IFACE="veth_source" +SOURCE_TEST_IP_ADDR="2001:0DB8:1::0:1/96" + +SINK_TEST_IFACE="veth_sink" +# ${SINK_TEST_IFACE} is populated with the following range of IPv6 addresses: +# 2001:0DB8:1::1:1 to 2001:0DB8:1::1:${IPV6_NEXTHOP_ADDR_COUNT} +SINK_LOOPBACK_IFACE="lo" +SINK_LOOPBACK_IP_MASK="128" +SINK_LOOPBACK_IP_ADDR="2001:0DB8:2::1:1" + +nexthop_ip_list="" +termination_signal="" +kernel_softlokup_panic_prev_val="" + +terminate_ns_processes_by_pattern() { + local ns=$1 + local pattern=$2 + + for pid in $(ip netns pids ${ns}); do + [ -e /proc/$pid/cmdline ] && grep -qe "${pattern}" /proc/$pid/cmdline && kill -9 $pid + done +} + +cleanup() { + echo "info: cleaning up namespaces and terminating all processes within them..." + + + # Terminate iperf3 instances running in the source_ns. To avoid race + # conditions, first iterate over the PIDs and terminate those + # associated with the bash shells running the + # `while true; do iperf3 -c ...; done` loops. In a second iteration, + # terminate the individual `iperf3 -c ...` instances. + terminate_ns_processes_by_pattern ${source_ns} while + terminate_ns_processes_by_pattern ${source_ns} iperf3 + + # Repeat the same process for sink_ns + terminate_ns_processes_by_pattern ${sink_ns} while + terminate_ns_processes_by_pattern ${sink_ns} iperf3 + + # Check if any iperf3 instances are still running. This could happen + # if a core has entered an infinite loop and the timeout for detecting + # the soft lockup has not expired, but either the test interval has + # already elapsed or the test was terminated manually (e.g., with ^C) + for pid in $(ip netns pids ${source_ns}); do + if [ -e /proc/$pid/cmdline ] && grep -qe 'iperf3' /proc/$pid/cmdline; then + echo "FAIL: unable to terminate some iperf3 instances. Soft lockup is underway. A kernel panic is on the way!" + exit ${ksft_fail} + fi + done + + if [ "$termination_signal" == "SIGINT" ]; then + echo "SKIP: Termination due to ^C (SIGINT)" + elif [ "$termination_signal" == "SIGALRM" ]; then + echo "PASS: No kernel soft lockup occurred during this ${TEST_DURATION} second test" + fi + + cleanup_ns ${source_ns} ${sink_ns} + + sysctl -qw kernel.softlockup_panic=${kernel_softlokup_panic_prev_val} +} + +setup_prepare() { + setup_ns source_ns sink_ns + + ip -n ${source_ns} link add name ${SOURCE_TEST_IFACE} type veth peer name ${SINK_TEST_IFACE} netns ${sink_ns} + + # Setting up the Source namespace + ip -n ${source_ns} addr add ${SOURCE_TEST_IP_ADDR} dev ${SOURCE_TEST_IFACE} + ip -n ${source_ns} link set dev ${SOURCE_TEST_IFACE} qlen 10000 + ip -n ${source_ns} link set dev ${SOURCE_TEST_IFACE} up + ip netns exec ${source_ns} sysctl -qw net.ipv6.fib_multipath_hash_policy=1 + + # Setting up the Sink namespace + ip -n ${sink_ns} addr add ${SINK_LOOPBACK_IP_ADDR}/${SINK_LOOPBACK_IP_MASK} dev ${SINK_LOOPBACK_IFACE} + ip -n ${sink_ns} link set dev ${SINK_LOOPBACK_IFACE} up + ip netns exec ${sink_ns} sysctl -qw net.ipv6.conf.${SINK_LOOPBACK_IFACE}.forwarding=1 + + ip -n ${sink_ns} link set ${SINK_TEST_IFACE} up + ip netns exec ${sink_ns} sysctl -qw net.ipv6.conf.${SINK_TEST_IFACE}.forwarding=1 + + + # Populate nexthop IPv6 addresses on the test interface in the sink_ns + echo "info: populating ${IPV6_NEXTHOP_ADDR_COUNT} IPv6 addresses on the ${SINK_TEST_IFACE} interface ..." + for IP in $(seq 1 ${IPV6_NEXTHOP_ADDR_COUNT}); do + ip -n ${sink_ns} addr add ${IPV6_NEXTHOP_PREFIX}::$(printf "1:%x" "${IP}")/${IPV6_NEXTHOP_ADDR_MASK} dev ${SINK_TEST_IFACE}; + done + + # Preparing list of nexthops + for IP in $(seq 1 ${IPV6_NEXTHOP_ADDR_COUNT}); do + nexthop_ip_list=$nexthop_ip_list" nexthop via ${IPV6_NEXTHOP_PREFIX}::$(printf "1:%x" $IP) dev ${SOURCE_TEST_IFACE} weight 1" + done +} + + +test_soft_lockup_during_routing_table_refresh() { + # Start num_of_iperf_servers iperf3 servers in the sink_ns namespace, + # each listening on ports starting at 5001 and incrementing + # sequentially. Since iperf3 instances may terminate unexpectedly, a + # while loop is used to automatically restart them in such cases. + echo "info: starting ${num_of_iperf_servers} iperf3 servers in the sink_ns namespace ..." + for i in $(seq 1 ${num_of_iperf_servers}); do + cmd="iperf3 --bind ${SINK_LOOPBACK_IP_ADDR} -s -p $(printf '5%03d' ${i}) --rcv-timeout 200 &>/dev/null" + ip netns exec ${sink_ns} bash -c "while true; do ${cmd}; done &" &>/dev/null + done + + # Wait for the iperf3 servers to be ready + for i in $(seq ${num_of_iperf_servers}); do + port=$(printf '5%03d' ${i}); + wait_local_port_listen ${sink_ns} ${port} tcp + done + + # Continuously refresh the routing table in the background within + # the source_ns namespace + ip netns exec ${source_ns} bash -c " + while \$(ip netns list | grep -q ${source_ns}); do + ip -6 route add ${SINK_LOOPBACK_IP_ADDR}/${SINK_LOOPBACK_IP_MASK} ${nexthop_ip_list}; + sleep ${ROUTING_TABLE_REFRESH_PERIOD}; + ip -6 route delete ${SINK_LOOPBACK_IP_ADDR}/${SINK_LOOPBACK_IP_MASK}; + done &" + + # Start num_of_iperf_servers iperf3 clients in the source_ns namespace, + # each sending TCP traffic on sequential ports starting at 5001. + # Since iperf3 instances may terminate unexpectedly (e.g., if the route + # to the server is deleted in the background during a route refresh), a + # while loop is used to automatically restart them in such cases. + echo "info: starting ${num_of_iperf_servers} iperf3 clients in the source_ns namespace ..." + for i in $(seq 1 ${num_of_iperf_servers}); do + cmd="iperf3 -c ${SINK_LOOPBACK_IP_ADDR} -p $(printf '5%03d' ${i}) --length 64 --bitrate ${IPERF3_BITRATE} -t 0 --connect-timeout 150 &>/dev/null" + ip netns exec ${source_ns} bash -c "while true; do ${cmd}; done &" &>/dev/null + done + + echo "info: IPv6 routing table is being updated at the rate of $(echo "1/${ROUTING_TABLE_REFRESH_PERIOD}" | bc)/s for ${TEST_DURATION} seconds ..." + echo "info: A kernel soft lockup, if detected, results in a kernel panic!" + + wait +} + +# Make sure 'iperf3' is installed, skip the test otherwise +if [ ! -x "$(command -v "iperf3")" ]; then + echo "SKIP: 'iperf3' is not installed. Skipping the test." + exit ${ksft_skip} +fi + +# Determine the number of cores on the machine +num_of_iperf_servers=$(( $(nproc)/2 )) + +# Check if we are running on a multi-core machine, skip the test otherwise +if [ "${num_of_iperf_servers}" -eq 0 ]; then + echo "SKIP: This test is not valid on a single core machine!" + exit ${ksft_skip} +fi + +# Since the kernel soft lockup we're testing causes at least one core to enter +# an infinite loop, destabilizing the host and likely affecting subsequent +# tests, we trigger a kernel panic instead of reporting a failure and +# continuing +kernel_softlokup_panic_prev_val=$(sysctl -n kernel.softlockup_panic) +sysctl -qw kernel.softlockup_panic=1 + +handle_sigint() { + termination_signal="SIGINT" + cleanup + exit ${ksft_skip} +} + +handle_sigalrm() { + termination_signal="SIGALRM" + cleanup + exit ${ksft_pass} +} + +trap handle_sigint SIGINT +trap handle_sigalrm SIGALRM + +(sleep ${TEST_DURATION} && kill -s SIGALRM $$)& + +setup_prepare +test_soft_lockup_during_routing_table_refresh -- 2.43.0

11 months

3
2
0 0

[PATCH net-next 0/8] macsec: inherit lower device's features and TSO limits when offloading

by Sabrina Dubroca

When macsec is offloaded to a NIC, we can take advantage of some of its features, mainly TSO and checksumming. This increases performance significantly. Some features cannot be inherited, because they require additional ops that aren't provided by the macsec netdevice. We also need to inherit TSO limits from the lower device, like VLAN/macvlan devices do. This series also moves the existing macsec offload selftest to the netdevsim selftests before adding tests for the new features. To allow this new selftest to work, netdevsim's hw_features are expanded. Sabrina Dubroca (8): netdevsim: add more hw_features selftests: netdevsim: add a test checking ethtool features macsec: add some of the lower device's features when offloading macsec: clean up local variables in macsec_notify macsec: inherit lower device's TSO limits when offloading selftests: move macsec offload tests from net/rtnetlink to drivers/net/netdvesim selftests: netdevsim: add test toggling macsec offload selftests: netdevsim: add ethtool features to macsec offload tests drivers/net/macsec.c | 64 +++++++--- drivers/net/netdevsim/netdev.c | 6 +- .../selftests/drivers/net/netdevsim/Makefile | 2 + .../selftests/drivers/net/netdevsim/config | 1 + .../drivers/net/netdevsim/ethtool-features.sh | 31 +++++ .../drivers/net/netdevsim/macsec-offload.sh | 117 ++++++++++++++++++ tools/testing/selftests/net/rtnetlink.sh | 68 ---------- 7 files changed, 200 insertions(+), 89 deletions(-) create mode 100644 tools/testing/selftests/drivers/net/netdevsim/ethtool-features.sh create mode 100755 tools/testing/selftests/drivers/net/netdevsim/macsec-offload.sh -- 2.47.0

11 months

3
17
0 0

[PATCH net-next v3 6/7] selftests: net: lib: Add kill_process

by Petr Machata

A number of selftests run processes in the background and need to kill them afterwards. Instead for everyone to open-code the kill / wait / redirect mantra, add a helper in net/lib.sh. Convert existing open-code sites. Signed-off-by: Petr Machata <petrm(a)nvidia.com> Acked-by: Shuah Khan <skhan(a)linuxfoundation.org> Reviewed-by: Amit Cohen <amcohen(a)nvidia.com> --- Notes: CC: Shuah Khan <shuah(a)kernel.org> CC: Benjamin Poirier <bpoirier(a)nvidia.com> CC: Hangbin Liu <liuhangbin(a)gmail.com> CC: linux-kselftest(a)vger.kernel.org CC: Jiri Pirko <jiri(a)resnulli.us> CC: Andrew Lunn <andrew+netdev(a)lunn.ch> .../selftests/drivers/net/mlxsw/devlink_trap.sh | 2 +- .../drivers/net/mlxsw/devlink_trap_l3_drops.sh | 4 ++-- .../drivers/net/mlxsw/devlink_trap_l3_exceptions.sh | 12 ++++++------ .../drivers/net/mlxsw/devlink_trap_tunnel_ipip.sh | 4 ++-- .../drivers/net/mlxsw/devlink_trap_tunnel_ipip6.sh | 4 ++-- .../drivers/net/mlxsw/devlink_trap_tunnel_vxlan.sh | 4 ++-- .../net/mlxsw/devlink_trap_tunnel_vxlan_ipv6.sh | 4 ++-- .../testing/selftests/drivers/net/mlxsw/tc_sample.sh | 4 ++-- .../drivers/net/netdevsim/fib_notifications.sh | 6 +++--- tools/testing/selftests/net/drop_monitor_tests.sh | 2 +- tools/testing/selftests/net/fib_tests.sh | 8 ++++---- .../testing/selftests/net/forwarding/devlink_lib.sh | 2 +- tools/testing/selftests/net/forwarding/lib.sh | 3 +-- tools/testing/selftests/net/forwarding/tc_police.sh | 8 ++++---- tools/testing/selftests/net/lib.sh | 8 ++++++++ 15 files changed, 41 insertions(+), 34 deletions(-) diff --git a/tools/testing/selftests/drivers/net/mlxsw/devlink_trap.sh b/tools/testing/selftests/drivers/net/mlxsw/devlink_trap.sh index 89b55e946eed..36055279ba92 100755 --- a/tools/testing/selftests/drivers/net/mlxsw/devlink_trap.sh +++ b/tools/testing/selftests/drivers/net/mlxsw/devlink_trap.sh @@ -116,7 +116,7 @@ dev_del_test() log_test "Device delete" - kill $mz_pid && wait $mz_pid &> /dev/null + kill_process $mz_pid } trap cleanup EXIT diff --git a/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_l3_drops.sh b/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_l3_drops.sh index 160891dcb4bc..db5806d189bb 100755 --- a/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_l3_drops.sh +++ b/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_l3_drops.sh @@ -595,7 +595,7 @@ irif_disabled_test() log_test "Ingress RIF disabled" - kill $mz_pid && wait $mz_pid &> /dev/null + kill_process $mz_pid ip link set dev $rp1 nomaster __addr_add_del $rp1 add 192.0.2.2/24 2001:db8:1::2/64 ip link del dev br0 type bridge @@ -645,7 +645,7 @@ erif_disabled_test() log_test "Egress RIF disabled" - kill $mz_pid && wait $mz_pid &> /dev/null + kill_process $mz_pid __addr_add_del $rp1 add 192.0.2.2/24 2001:db8:1::2/64 ip link del dev br0 type bridge devlink_trap_action_set $trap_name "drop" diff --git a/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_l3_exceptions.sh b/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_l3_exceptions.sh index 190c1b6b5365..5d6d88b600f0 100755 --- a/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_l3_exceptions.sh +++ b/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_l3_exceptions.sh @@ -202,7 +202,7 @@ mtu_value_is_too_small_test() mtu_restore $rp2 - kill $mz_pid && wait $mz_pid &> /dev/null + kill_process $mz_pid tc filter del dev $h1 ingress protocol ip pref 1 handle 101 flower } @@ -235,7 +235,7 @@ __ttl_value_is_too_small_test() log_test "TTL value is too small: TTL=$ttl_val" - kill $mz_pid && wait $mz_pid &> /dev/null + kill_process $mz_pid tc filter del dev $h1 ingress protocol ip pref 1 handle 101 flower } @@ -299,7 +299,7 @@ __mc_reverse_path_forwarding_test() log_test "Multicast reverse path forwarding: $desc" - kill $mz_pid && wait $mz_pid &> /dev/null + kill_process $mz_pid tc filter del dev $rp2 egress protocol $proto pref 1 handle 101 flower } @@ -347,7 +347,7 @@ __reject_route_test() log_test "Reject route: $desc" - kill $mz_pid && wait $mz_pid &> /dev/null + kill_process $mz_pid ip route del unreachable $unreachable tc filter del dev $h1 ingress protocol $proto pref 1 handle 101 flower } @@ -542,7 +542,7 @@ ipv4_lpm_miss_test() log_test "LPM miss: IPv4" - kill $mz_pid && wait $mz_pid &> /dev/null + kill_process $mz_pid vrf_without_routes_destroy } @@ -569,7 +569,7 @@ ipv6_lpm_miss_test() log_test "LPM miss: IPv6" - kill $mz_pid && wait $mz_pid &> /dev/null + kill_process $mz_pid vrf_without_routes_destroy } diff --git a/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_tunnel_ipip.sh b/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_tunnel_ipip.sh index e9a82cae8c9a..4ac1dae92d0f 100755 --- a/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_tunnel_ipip.sh +++ b/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_tunnel_ipip.sh @@ -176,7 +176,7 @@ ecn_decap_test() log_test "$desc: Inner ECN is not ECT and outer is $ecn_desc" - kill $mz_pid && wait $mz_pid &> /dev/null + kill_process $mz_pid tc filter del dev $swp1 egress protocol ip pref 1 handle 101 flower } @@ -207,7 +207,7 @@ no_matching_tunnel_test() log_test "$desc" - kill $mz_pid && wait $mz_pid &> /dev/null + kill_process $mz_pid tc filter del dev $swp1 egress protocol ip pref 1 handle 101 flower } diff --git a/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_tunnel_ipip6.sh b/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_tunnel_ipip6.sh index 878125041fc3..fce885184404 100755 --- a/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_tunnel_ipip6.sh +++ b/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_tunnel_ipip6.sh @@ -176,7 +176,7 @@ ecn_decap_test() log_test "$desc: Inner ECN is not ECT and outer is $ecn_desc" - kill $mz_pid && wait $mz_pid &> /dev/null + kill_process $mz_pid tc filter del dev $swp1 egress protocol ipv6 pref 1 handle 101 flower } @@ -207,7 +207,7 @@ no_matching_tunnel_test() log_test "$desc" - kill $mz_pid && wait $mz_pid &> /dev/null + kill_process $mz_pid tc filter del dev $swp1 egress protocol ipv6 pref 1 handle 101 flower } diff --git a/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_tunnel_vxlan.sh b/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_tunnel_vxlan.sh index 5f6eb965cfd1..7aca8e5922cf 100755 --- a/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_tunnel_vxlan.sh +++ b/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_tunnel_vxlan.sh @@ -183,7 +183,7 @@ ecn_decap_test() log_test "$desc: Inner ECN is not ECT and outer is $ecn_desc" - kill $mz_pid && wait $mz_pid &> /dev/null + kill_process $mz_pid tc filter del dev $swp1 egress protocol ip pref 1 handle 101 flower } @@ -253,7 +253,7 @@ corrupted_packet_test() log_test "$desc" - kill $mz_pid && wait $mz_pid &> /dev/null + kill_process $mz_pid tc filter del dev $swp1 egress protocol ip pref 1 handle 101 flower } diff --git a/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_tunnel_vxlan_ipv6.sh b/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_tunnel_vxlan_ipv6.sh index f6c16cbb6cf7..4599c331240b 100755 --- a/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_tunnel_vxlan_ipv6.sh +++ b/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_tunnel_vxlan_ipv6.sh @@ -188,7 +188,7 @@ ecn_decap_test() log_test "$desc: Inner ECN is not ECT and outer is $ecn_desc" - kill $mz_pid && wait $mz_pid &> /dev/null + kill_process $mz_pid tc filter del dev $swp1 egress protocol ipv6 pref 1 handle 101 flower } @@ -262,7 +262,7 @@ corrupted_packet_test() log_test "$desc" - kill $mz_pid && wait $mz_pid &> /dev/null + kill_process $mz_pid tc filter del dev $swp1 egress protocol ipv6 pref 1 handle 101 flower } diff --git a/tools/testing/selftests/drivers/net/mlxsw/tc_sample.sh b/tools/testing/selftests/drivers/net/mlxsw/tc_sample.sh index 83a0210e7544..bc7ea2df49fb 100755 --- a/tools/testing/selftests/drivers/net/mlxsw/tc_sample.sh +++ b/tools/testing/selftests/drivers/net/mlxsw/tc_sample.sh @@ -218,7 +218,7 @@ psample_capture_start() psample_capture_stop() { - { kill %% && wait %%; } 2>/dev/null + kill_process %% } __tc_sample_rate_test() @@ -499,7 +499,7 @@ tc_sample_md_out_tc_occ_test() backlog=$(tc -j -p -s qdisc show dev $rp2 | jq '.[0]["backlog"]') # Kill mausezahn. - { kill %% && wait %%; } 2>/dev/null + kill_process %% psample_capture_stop diff --git a/tools/testing/selftests/drivers/net/netdevsim/fib_notifications.sh b/tools/testing/selftests/drivers/net/netdevsim/fib_notifications.sh index 8d91191a098c..9896580c3d85 100755 --- a/tools/testing/selftests/drivers/net/netdevsim/fib_notifications.sh +++ b/tools/testing/selftests/drivers/net/netdevsim/fib_notifications.sh @@ -94,7 +94,7 @@ route_addition_check() sleep 1 $IP route add $route dev dummy1 sleep 1 - kill %% && wait %% &> /dev/null + kill_process %% route_notify_check $outfile $expected_num_notifications $offload_failed rm -f $outfile @@ -148,7 +148,7 @@ route_deletion_check() sleep 1 $IP route del $route dev dummy1 sleep 1 - kill %% && wait %% &> /dev/null + kill_process %% route_notify_check $outfile $expected_num_notifications rm -f $outfile @@ -191,7 +191,7 @@ route_replacement_check() sleep 1 $IP route replace $route dev dummy2 sleep 1 - kill %% && wait %% &> /dev/null + kill_process %% route_notify_check $outfile $expected_num_notifications rm -f $outfile diff --git a/tools/testing/selftests/net/drop_monitor_tests.sh b/tools/testing/selftests/net/drop_monitor_tests.sh index 7c4818c971fc..507d0a82f5f0 100755 --- a/tools/testing/selftests/net/drop_monitor_tests.sh +++ b/tools/testing/selftests/net/drop_monitor_tests.sh @@ -77,7 +77,7 @@ sw_drops_test() rm ${dir}/packets.pcap - { kill %% && wait %%; } 2>/dev/null + kill_process %% timeout 5 dwdump -o sw -w ${dir}/packets.pcap (( $(tshark -r ${dir}/packets.pcap \ -Y 'ip.dst == 192.0.2.10' 2> /dev/null | wc -l) == 0)) diff --git a/tools/testing/selftests/net/fib_tests.sh b/tools/testing/selftests/net/fib_tests.sh index 5f3c28fc8624..3ea6f886a210 100755 --- a/tools/testing/selftests/net/fib_tests.sh +++ b/tools/testing/selftests/net/fib_tests.sh @@ -689,7 +689,7 @@ fib6_notify_test() log_test $ret 0 "ipv6 route add notify" - { kill %% && wait %%; } 2>/dev/null + kill_process %% #rm errors.txt @@ -736,7 +736,7 @@ fib_notify_test() log_test $ret 0 "ipv4 route add notify" - { kill %% && wait %%; } 2>/dev/null + kill_process %% rm errors.txt @@ -2328,7 +2328,7 @@ ipv4_mangle_test() $IP route del table 123 172.16.101.0/24 dev veth1 $IP rule del pref 100 - { kill %% && wait %%; } 2>/dev/null + kill_process %% rm $tmp_file route_cleanup @@ -2386,7 +2386,7 @@ ipv6_mangle_test() $IP -6 route del table 123 2001:db8:101::/64 dev veth1 $IP -6 rule del pref 100 - { kill %% && wait %%; } 2>/dev/null + kill_process %% rm $tmp_file route_cleanup diff --git a/tools/testing/selftests/net/forwarding/devlink_lib.sh b/tools/testing/selftests/net/forwarding/devlink_lib.sh index 62a05bca1e82..18afa89ebbcc 100644 --- a/tools/testing/selftests/net/forwarding/devlink_lib.sh +++ b/tools/testing/selftests/net/forwarding/devlink_lib.sh @@ -501,7 +501,7 @@ devlink_trap_drop_cleanup() local pref=$1; shift local handle=$1; shift - kill $mz_pid && wait $mz_pid &> /dev/null + kill_process $mz_pid tc filter del dev $dev egress protocol $proto pref $pref handle $handle flower } diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh index 8625e3c99f55..7337f398f9cc 100644 --- a/tools/testing/selftests/net/forwarding/lib.sh +++ b/tools/testing/selftests/net/forwarding/lib.sh @@ -1574,8 +1574,7 @@ stop_traffic() { local pid=${1-%%}; shift - # Suppress noise from killing mausezahn. - { kill $pid && wait $pid; } 2>/dev/null + kill_process "$pid" } declare -A cappid diff --git a/tools/testing/selftests/net/forwarding/tc_police.sh b/tools/testing/selftests/net/forwarding/tc_police.sh index 5103f64a71d6..509fdedfcfa1 100755 --- a/tools/testing/selftests/net/forwarding/tc_police.sh +++ b/tools/testing/selftests/net/forwarding/tc_police.sh @@ -148,7 +148,7 @@ police_common_test() log_test "$test_name" - { kill %% && wait %%; } 2>/dev/null + kill_process %% tc filter del dev $h2 ingress protocol ip pref 1 handle 101 flower } @@ -198,7 +198,7 @@ police_shared_common_test() log_test "$test_name" - { kill %% && wait %%; } 2>/dev/null + kill_process %% } police_shared_test() @@ -278,7 +278,7 @@ police_mirror_common_test() log_test "$test_name" - { kill %% && wait %%; } 2>/dev/null + kill_process %% tc filter del dev $pol_if $dir protocol ip pref 1 handle 101 flower tc filter del dev $h3 ingress protocol ip pref 1 handle 101 flower tc filter del dev $h2 ingress protocol ip pref 1 handle 101 flower @@ -320,7 +320,7 @@ police_pps_common_test() log_test "$test_name" - { kill %% && wait %%; } 2>/dev/null + kill_process %% tc filter del dev $h2 ingress protocol ip pref 1 handle 101 flower } diff --git a/tools/testing/selftests/net/lib.sh b/tools/testing/selftests/net/lib.sh index 6bcf5d13879d..24f63e45735d 100644 --- a/tools/testing/selftests/net/lib.sh +++ b/tools/testing/selftests/net/lib.sh @@ -434,3 +434,11 @@ xfail_on_veth() "$@" fi } + +kill_process() +{ + local pid=$1; shift + + # Suppress noise from killing the process. + { kill $pid && wait $pid; } 2>/dev/null +} -- 2.45.0

11 months

1
0
0 0

[PATCH net-next v3 5/7] selftests: net: lib: Move checks from forwarding/lib.sh here

by Petr Machata

For logging to be useful, something has to set RET and retmsg by calling ret_set_ksft_status(). There is a suite of functions to that end in forwarding/lib: check_err, check_fail et.al. Move them to net/lib.sh so that every net test can use them. Existing lib.sh users might be using these same names for their functions. However lib.sh is always sourced near the top of the file (checked), and whatever new definitions will simply override the ones provided by lib.sh. Signed-off-by: Petr Machata <petrm(a)nvidia.com> Reviewed-by: Amit Cohen <amcohen(a)nvidia.com> Acked-by: Shuah Khan <skhan(a)linuxfoundation.org> --- Notes: CC: Shuah Khan <shuah(a)kernel.org> CC: Benjamin Poirier <bpoirier(a)nvidia.com> CC: Hangbin Liu <liuhangbin(a)gmail.com> CC: linux-kselftest(a)vger.kernel.org CC: Jiri Pirko <jiri(a)resnulli.us> tools/testing/selftests/net/forwarding/lib.sh | 73 ------------------- tools/testing/selftests/net/lib.sh | 73 +++++++++++++++++++ 2 files changed, 73 insertions(+), 73 deletions(-) diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh index d28dbf27c1f0..8625e3c99f55 100644 --- a/tools/testing/selftests/net/forwarding/lib.sh +++ b/tools/testing/selftests/net/forwarding/lib.sh @@ -445,79 +445,6 @@ done ############################################################################## # Helpers -# Whether FAILs should be interpreted as XFAILs. Internal. -FAIL_TO_XFAIL= - -check_err() -{ - local err=$1 - local msg=$2 - - if ((err)); then - if [[ $FAIL_TO_XFAIL = yes ]]; then - ret_set_ksft_status $ksft_xfail "$msg" - else - ret_set_ksft_status $ksft_fail "$msg" - fi - fi -} - -check_fail() -{ - local err=$1 - local msg=$2 - - check_err $((!err)) "$msg" -} - -check_err_fail() -{ - local should_fail=$1; shift - local err=$1; shift - local what=$1; shift - - if ((should_fail)); then - check_fail $err "$what succeeded, but should have failed" - else - check_err $err "$what failed" - fi -} - -xfail() -{ - FAIL_TO_XFAIL=yes "$@" -} - -xfail_on_slow() -{ - if [[ $KSFT_MACHINE_SLOW = yes ]]; then - FAIL_TO_XFAIL=yes "$@" - else - "$@" - fi -} - -omit_on_slow() -{ - if [[ $KSFT_MACHINE_SLOW != yes ]]; then - "$@" - fi -} - -xfail_on_veth() -{ - local dev=$1; shift - local kind - - kind=$(ip -j -d link show dev $dev | - jq -r '.[].linkinfo.info_kind') - if [[ $kind = veth ]]; then - FAIL_TO_XFAIL=yes "$@" - else - "$@" - fi -} - not() { "$@" diff --git a/tools/testing/selftests/net/lib.sh b/tools/testing/selftests/net/lib.sh index 4f52b8e48a3a..6bcf5d13879d 100644 --- a/tools/testing/selftests/net/lib.sh +++ b/tools/testing/selftests/net/lib.sh @@ -361,3 +361,76 @@ tests_run() $current_test done } + +# Whether FAILs should be interpreted as XFAILs. Internal. +FAIL_TO_XFAIL= + +check_err() +{ + local err=$1 + local msg=$2 + + if ((err)); then + if [[ $FAIL_TO_XFAIL = yes ]]; then + ret_set_ksft_status $ksft_xfail "$msg" + else + ret_set_ksft_status $ksft_fail "$msg" + fi + fi +} + +check_fail() +{ + local err=$1 + local msg=$2 + + check_err $((!err)) "$msg" +} + +check_err_fail() +{ + local should_fail=$1; shift + local err=$1; shift + local what=$1; shift + + if ((should_fail)); then + check_fail $err "$what succeeded, but should have failed" + else + check_err $err "$what failed" + fi +} + +xfail() +{ + FAIL_TO_XFAIL=yes "$@" +} + +xfail_on_slow() +{ + if [[ $KSFT_MACHINE_SLOW = yes ]]; then + FAIL_TO_XFAIL=yes "$@" + else + "$@" + fi +} + +omit_on_slow() +{ + if [[ $KSFT_MACHINE_SLOW != yes ]]; then + "$@" + fi +} + +xfail_on_veth() +{ + local dev=$1; shift + local kind + + kind=$(ip -j -d link show dev $dev | + jq -r '.[].linkinfo.info_kind') + if [[ $kind = veth ]]; then + FAIL_TO_XFAIL=yes "$@" + else + "$@" + fi +} -- 2.45.0

11 months

1
0
0 0

[PATCH net-next v3 4/7] selftests: net: lib: Move tests_run from forwarding/lib.sh here

by Petr Machata

It would be good to use the same mechanism for scheduling and dispatching general net tests as the many forwarding tests already use. To that end, move the logging helpers to net/lib.sh so that every net test can use them. Existing lib.sh users might be using the name themselves. However lib.sh is always sourced near the top of the file (checked), and whatever new definition will simply override the one provided by lib.sh. Signed-off-by: Petr Machata <petrm(a)nvidia.com> Reviewed-by: Amit Cohen <amcohen(a)nvidia.com> Acked-by: Shuah Khan <skhan(a)linuxfoundation.org> --- Notes: CC: Shuah Khan <shuah(a)kernel.org> CC: Benjamin Poirier <bpoirier(a)nvidia.com> CC: Hangbin Liu <liuhangbin(a)gmail.com> CC: linux-kselftest(a)vger.kernel.org CC: Jiri Pirko <jiri(a)resnulli.us> tools/testing/selftests/net/forwarding/lib.sh | 10 ---------- tools/testing/selftests/net/lib.sh | 10 ++++++++++ 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh index 41dd14c42c48..d28dbf27c1f0 100644 --- a/tools/testing/selftests/net/forwarding/lib.sh +++ b/tools/testing/selftests/net/forwarding/lib.sh @@ -1285,16 +1285,6 @@ matchall_sink_create() action drop } -tests_run() -{ - local current_test - - for current_test in ${TESTS:-$ALL_TESTS}; do - in_defer_scope \ - $current_test - done -} - cleanup() { pre_cleanup diff --git a/tools/testing/selftests/net/lib.sh b/tools/testing/selftests/net/lib.sh index 691318b1ec55..4f52b8e48a3a 100644 --- a/tools/testing/selftests/net/lib.sh +++ b/tools/testing/selftests/net/lib.sh @@ -351,3 +351,13 @@ log_info() echo "INFO: $msg" } + +tests_run() +{ + local current_test + + for current_test in ${TESTS:-$ALL_TESTS}; do + in_defer_scope \ + $current_test + done +} -- 2.45.0

11 months

1
0
0 0

[PATCH net-next v3 3/7] selftests: net: lib: Move logging from forwarding/lib.sh here

by Petr Machata

Many net selftests invent their own logging helpers. These really should be in a library sourced by these tests. Currently forwarding/lib.sh has a suite of perfectly fine logging helpers, but sourcing a forwarding/ library from a higher-level directory smells of layering violation. In this patch, move the logging helpers to net/lib.sh so that every net test can use them. Together with the logging helpers, it's also necessary to move pause_on_fail(), and EXIT_STATUS and RET. Existing lib.sh users might be using these same names for their functions or variables. However lib.sh is always sourced near the top of the file (checked), and whatever new definitions will simply override the ones provided by lib.sh. Signed-off-by: Petr Machata <petrm(a)nvidia.com> Reviewed-by: Amit Cohen <amcohen(a)nvidia.com> Acked-by: Shuah Khan <skhan(a)linuxfoundation.org> --- Notes: CC: Shuah Khan <shuah(a)kernel.org> CC: Benjamin Poirier <bpoirier(a)nvidia.com> CC: Hangbin Liu <liuhangbin(a)gmail.com> CC: linux-kselftest(a)vger.kernel.org CC: Jiri Pirko <jiri(a)resnulli.us> tools/testing/selftests/net/forwarding/lib.sh | 113 ----------------- tools/testing/selftests/net/lib.sh | 115 ++++++++++++++++++ 2 files changed, 115 insertions(+), 113 deletions(-) diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh index 89c25f72b10c..41dd14c42c48 100644 --- a/tools/testing/selftests/net/forwarding/lib.sh +++ b/tools/testing/selftests/net/forwarding/lib.sh @@ -48,7 +48,6 @@ declare -A NETIFS=( : "${WAIT_TIME:=5}" # Whether to pause on, respectively, after a failure and before cleanup. -: "${PAUSE_ON_FAIL:=no}" : "${PAUSE_ON_CLEANUP:=no}" # Whether to create virtual interfaces, and what netdevice type they should be. @@ -446,22 +445,6 @@ done ############################################################################## # Helpers -# Exit status to return at the end. Set in case one of the tests fails. -EXIT_STATUS=0 -# Per-test return value. Clear at the beginning of each test. -RET=0 - -ret_set_ksft_status() -{ - local ksft_status=$1; shift - local msg=$1; shift - - RET=$(ksft_status_merge $RET $ksft_status) - if (( $? )); then - retmsg=$msg - fi -} - # Whether FAILs should be interpreted as XFAILs. Internal. FAIL_TO_XFAIL= @@ -535,102 +518,6 @@ xfail_on_veth() fi } -log_test_result() -{ - local test_name=$1; shift - local opt_str=$1; shift - local result=$1; shift - local retmsg=$1; shift - - printf "TEST: %-60s [%s]\n" "$test_name $opt_str" "$result" - if [[ $retmsg ]]; then - printf "\t%s\n" "$retmsg" - fi -} - -pause_on_fail() -{ - if [[ $PAUSE_ON_FAIL == yes ]]; then - echo "Hit enter to continue, 'q' to quit" - read a - [[ $a == q ]] && exit 1 - fi -} - -handle_test_result_pass() -{ - local test_name=$1; shift - local opt_str=$1; shift - - log_test_result "$test_name" "$opt_str" " OK " -} - -handle_test_result_fail() -{ - local test_name=$1; shift - local opt_str=$1; shift - - log_test_result "$test_name" "$opt_str" FAIL "$retmsg" - pause_on_fail -} - -handle_test_result_xfail() -{ - local test_name=$1; shift - local opt_str=$1; shift - - log_test_result "$test_name" "$opt_str" XFAIL "$retmsg" - pause_on_fail -} - -handle_test_result_skip() -{ - local test_name=$1; shift - local opt_str=$1; shift - - log_test_result "$test_name" "$opt_str" SKIP "$retmsg" -} - -log_test() -{ - local test_name=$1 - local opt_str=$2 - - if [[ $# -eq 2 ]]; then - opt_str="($opt_str)" - fi - - if ((RET == ksft_pass)); then - handle_test_result_pass "$test_name" "$opt_str" - elif ((RET == ksft_xfail)); then - handle_test_result_xfail "$test_name" "$opt_str" - elif ((RET == ksft_skip)); then - handle_test_result_skip "$test_name" "$opt_str" - else - handle_test_result_fail "$test_name" "$opt_str" - fi - - EXIT_STATUS=$(ksft_exit_status_merge $EXIT_STATUS $RET) - return $RET -} - -log_test_skip() -{ - RET=$ksft_skip retmsg= log_test "$@" -} - -log_test_xfail() -{ - RET=$ksft_xfail retmsg= log_test "$@" -} - -log_info() -{ - local msg=$1 - - echo "INFO: $msg" -} - not() { "$@" diff --git a/tools/testing/selftests/net/lib.sh b/tools/testing/selftests/net/lib.sh index c8991cc6bf28..691318b1ec55 100644 --- a/tools/testing/selftests/net/lib.sh +++ b/tools/testing/selftests/net/lib.sh @@ -9,6 +9,9 @@ source "$net_dir/lib/sh/defer.sh" : "${WAIT_TIMEOUT:=20}" +# Whether to pause on after a failure. +: "${PAUSE_ON_FAIL:=no}" + BUSYWAIT_TIMEOUT=$((WAIT_TIMEOUT * 1000)) # ms # Kselftest framework constants. @@ -20,6 +23,11 @@ ksft_skip=4 # namespace list created by setup_ns NS_LIST=() +# Exit status to return at the end. Set in case one of the tests fails. +EXIT_STATUS=0 +# Per-test return value. Clear at the beginning of each test. +RET=0 + ############################################################################## # Helpers @@ -236,3 +244,110 @@ tc_rule_handle_stats_get() | jq ".[] | select(.options.handle == $handle) | \ .options.actions[0].stats$selector" } + +ret_set_ksft_status() +{ + local ksft_status=$1; shift + local msg=$1; shift + + RET=$(ksft_status_merge $RET $ksft_status) + if (( $? )); then + retmsg=$msg + fi +} + +log_test_result() +{ + local test_name=$1; shift + local opt_str=$1; shift + local result=$1; shift + local retmsg=$1; shift + + printf "TEST: %-60s [%s]\n" "$test_name $opt_str" "$result" + if [[ $retmsg ]]; then + printf "\t%s\n" "$retmsg" + fi +} + +pause_on_fail() +{ + if [[ $PAUSE_ON_FAIL == yes ]]; then + echo "Hit enter to continue, 'q' to quit" + read a + [[ $a == q ]] && exit 1 + fi +} + +handle_test_result_pass() +{ + local test_name=$1; shift + local opt_str=$1; shift + + log_test_result "$test_name" "$opt_str" " OK " +} + +handle_test_result_fail() +{ + local test_name=$1; shift + local opt_str=$1; shift + + log_test_result "$test_name" "$opt_str" FAIL "$retmsg" + pause_on_fail +} + +handle_test_result_xfail() +{ + local test_name=$1; shift + local opt_str=$1; shift + + log_test_result "$test_name" "$opt_str" XFAIL "$retmsg" + pause_on_fail +} + +handle_test_result_skip() +{ + local test_name=$1; shift + local opt_str=$1; shift + + log_test_result "$test_name" "$opt_str" SKIP "$retmsg" +} + +log_test() +{ + local test_name=$1 + local opt_str=$2 + + if [[ $# -eq 2 ]]; then + opt_str="($opt_str)" + fi + + if ((RET == ksft_pass)); then + handle_test_result_pass "$test_name" "$opt_str" + elif ((RET == ksft_xfail)); then + handle_test_result_xfail "$test_name" "$opt_str" + elif ((RET == ksft_skip)); then + handle_test_result_skip "$test_name" "$opt_str" + else + handle_test_result_fail "$test_name" "$opt_str" + fi + + EXIT_STATUS=$(ksft_exit_status_merge $EXIT_STATUS $RET) + return $RET +} + +log_test_skip() +{ + RET=$ksft_skip retmsg= log_test "$@" +} + +log_test_xfail() +{ + RET=$ksft_xfail retmsg= log_test "$@" +} + +log_info() +{ + local msg=$1 + + echo "INFO: $msg" +} -- 2.45.0

11 months

1
0
0 0

[PATCH v7 0/5] selftests: kvm: s390: Add ucontrol memory selftests

by Christoph Schlameuss

This patch series adds a some not yet picked selftests to the kvm s390x selftest suite. The additional test cases are covering: * Assert KVM_EXIT_S390_UCONTROL exit on not mapped memory access * Assert functionality of storage keys in ucontrol VM * Assert that memory region operations are rejected for ucontrol VMs Running the test cases requires sys_admin capabilities to start the ucontrol VM. This can be achieved by running as root or with a command like: sudo setpriv --reuid nobody --inh-caps -all,+sys_admin \ --ambient-caps -all,+sys_admin --bounding-set -all,+sys_admin \ ./ucontrol_test --- The patches in this series have been part of the previous patch series. The test cases added here do depend on the fixture added in the earlier patches. From v5 PATCH 7-9 the segment and page table generation has been removed and DAT has been disabled. Since DAT is not necessary to validate the KVM code. https://lore.kernel.org/kvm/20240807154512.316936-1-schlameuss@linux.ibm.co… v7: - skip uc_skey test when execution is in vsie v6: - add instruction intercept handling for skey specific instructions (iske, sske, rrbe) in addition to kss intercept to work properly on all machines - reorder local variables - fixup some method comments - add a patch correcting the IP.b value length a debug message v5: - rebased to current upstream master - corrected assertion on 0x00 to 0 - reworded fixup commit so that it can be merged on top of current upstream v4: - fix whitespaces in pointer function arguments (thanks Claudio) - fix whitespaces in comments (thanks Janosch) v3: - fix skey assertion (thanks Claudio) - introduce a wrapper around UCAS map and unmap ioctls to improve readability (Claudio) - add an displacement to accessed memory to assert translation intercepts actually point to segments to the uc_map_unmap test - add an misaligned failing mapping try to the uc_map_unmap test v2: - Reenable KSS intercept and handle it within skey test. - Modify the checked register between storing (sske) and reading (iske) it within the test program to make sure the. - Add an additional state assertion in the end of uc_skey - Fix some typos and white spaces. v1: - Remove segment and page table generation and disable DAT. This is not necessary to validate the KVM code. Christoph Schlameuss (5): selftests: kvm: s390: Add uc_map_unmap VM test case selftests: kvm: s390: Add uc_skey VM test case selftests: kvm: s390: Verify reject memory region operations for ucontrol VMs selftests: kvm: s390: Fix whitespace confusion in ucontrol test selftests: kvm: s390: correct IP.b length in uc_handle_sieic debug output .../selftests/kvm/include/s390x/processor.h | 6 + .../selftests/kvm/s390x/ucontrol_test.c | 321 +++++++++++++++++- 2 files changed, 319 insertions(+), 8 deletions(-) -- 2.47.0

11 months

2
7
0 0

[PATCH] kunit: string-stream: Fix a UAF bug in kunit_init_suite()

by Jinjie Ruan

In kunit_debugfs_create_suite(), if alloc_string_stream() fails in the kunit_suite_for_each_test_case() loop, the "suite->log = stream" has assigned before, and the error path only free the suite->log's stream memory but not set it to NULL in string_stream_destroy(), so the later string_stream_clear() of suite->log in kunit_init_suite() will cause below UAF bug. Set stream pointer to NULL after free in string_stream_destroy() to fix it. Unable to handle kernel paging request at virtual address 006440150000030d Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [006440150000030d] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: iio_test_gts industrialio_gts_helper cfg80211 rfkill ipv6 [last unloaded: iio_test_gts] CPU: 5 UID: 0 PID: 6253 Comm: modprobe Tainted: G B W N 6.12.0-rc4+ #458 Tainted: [B]=BAD_PAGE, [W]=WARN, [N]=TEST Hardware name: linux,dummy-virt (DT) pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : string_stream_clear+0x54/0x1ac lr : string_stream_clear+0x1a8/0x1ac sp : ffffffc080b47410 x29: ffffffc080b47410 x28: 006440550000030d x27: ffffff80c96b5e98 x26: ffffff80c96b5e80 x25: ffffffe461b3f6c0 x24: 0000000000000003 x23: ffffff80c96b5e88 x22: 1ffffff019cdf4fc x21: dfffffc000000000 x20: ffffff80ce6fa7e0 x19: 032202a80000186d x18: 0000000000001840 x17: 0000000000000000 x16: 0000000000000000 x15: ffffffe45c355cb4 x14: ffffffe45c35589c x13: ffffffe45c03da78 x12: ffffffb810168e75 x11: 1ffffff810168e74 x10: ffffffb810168e74 x9 : dfffffc000000000 x8 : 0000000000000004 x7 : 0000000000000003 x6 : 0000000000000001 x5 : ffffffc080b473a0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000001 x1 : ffffffe462fbf620 x0 : dfffffc000000000 Call trace: string_stream_clear+0x54/0x1ac __kunit_test_suites_init+0x108/0x1d8 kunit_exec_run_tests+0xb8/0x100 kunit_module_notify+0x400/0x55c notifier_call_chain+0xfc/0x3b4 blocking_notifier_call_chain+0x68/0x9c do_init_module+0x24c/0x5c8 load_module+0x4acc/0x4e90 init_module_from_file+0xd4/0x128 idempotent_init_module+0x2d4/0x57c __arm64_sys_finit_module+0xac/0x100 invoke_syscall+0x6c/0x258 el0_svc_common.constprop.0+0x160/0x22c do_el0_svc+0x44/0x5c el0_svc+0x48/0xb8 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194 Code: f9400753 d2dff800 f2fbffe0 d343fe7c (38e06b80) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception Cc: stable(a)vger.kernel.org Fixes: a3fdf784780c ("kunit: string-stream: Decouple string_stream from kunit") Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- lib/kunit/string-stream.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/kunit/string-stream.c b/lib/kunit/string-stream.c index 54f4fdcbfac8..00ad518b730b 100644 --- a/lib/kunit/string-stream.c +++ b/lib/kunit/string-stream.c @@ -178,6 +178,7 @@ void string_stream_destroy(struct string_stream *stream) string_stream_clear(stream); kfree(stream); + stream = NULL; } static void resource_free_string_stream(void *p) -- 2.34.1

11 months

3
6
0 0

[PATCH] selftests: hugetlb_dio: Check for initial conditions to skip in the start

by Muhammad Usama Anjum

The test should be skipped if initial conditions aren't fulfilled in the start instead of failing and outputting non-compliant TAP logs. This kind of failure pollutes the results. The initial conditions are: - The test should only execute if /tmp file can be allocated. - The test should only execute if huge pages are free. Signed-off-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> --- Before: TAP version 13 1..4 Bail out! Error opening file : Read-only file system (30) # Planned tests != run tests (4 != 0) # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0 After: TAP version 13 1..0 # SKIP Unable to allocate file: Read-only file system --- tools/testing/selftests/mm/hugetlb_dio.c | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/tools/testing/selftests/mm/hugetlb_dio.c b/tools/testing/selftests/mm/hugetlb_dio.c index f9ac20c657ec6..60001c142ce99 100644 --- a/tools/testing/selftests/mm/hugetlb_dio.c +++ b/tools/testing/selftests/mm/hugetlb_dio.c @@ -44,13 +44,6 @@ void run_dio_using_hugetlb(unsigned int start_off, unsigned int end_off) if (fd < 0) ksft_exit_fail_perror("Error opening file\n"); - /* Get the free huge pages before allocation */ - free_hpage_b = get_free_hugepages(); - if (free_hpage_b == 0) { - close(fd); - ksft_exit_skip("No free hugepage, exiting!\n"); - } - /* Allocate a hugetlb page */ orig_buffer = mmap(NULL, h_pagesize, mmap_prot, mmap_flags, -1, 0); if (orig_buffer == MAP_FAILED) { @@ -94,8 +87,20 @@ void run_dio_using_hugetlb(unsigned int start_off, unsigned int end_off) int main(void) { size_t pagesize = 0; + int fd; ksft_print_header(); + + /* Open the file to DIO */ + fd = open("/tmp", O_TMPFILE | O_RDWR | O_DIRECT, 0664); + if (fd < 0) + ksft_exit_skip("Unable to allocate file: %s\n", strerror(errno)); + close(fd); + + /* Check if huge pages are free */ + if (!get_free_hugepages()) + ksft_exit_skip("No free hugepage, exiting\n"); + ksft_set_plan(4); /* Get base page size */ -- 2.39.5

11 months

4
10
0 0

[PATCH v2 0/3] kunit: Add support for LoongArch

by Thomas Weißschuh

Enable LoongArch support in kunit. Example: $ ./tools/testing/kunit/kunit.py run --arch=loongarch --cross_compile=$CROSS_COMPILE [13:32:45] Configuring KUnit Kernel ... [13:32:45] Building KUnit Kernel ... Populating config with: $ make ARCH=loongarch olddefconfig CROSS_COMPILE=$CROSS_COMPILE Building with: $ make all compile_commands.json ARCH=loongarch --jobs=8 CROSS_COMPILE=$CROSS_COMPILE [13:32:48] Starting KUnit Kernel (1/1)... [13:32:48] ============================================================ Running tests with: $ qemu-system-loongarch64 -nodefaults -m 1024 -kernel .kunit/arch/loongarch/boot/vmlinux.elf -append 'kunit.enable=1 console=ttyS0 kunit_shutdown=poweroff' -no-reboot -nographic -serial stdio -machine virt -device pvpanic-pci -cpu max ... [13:33:14] ============================================================ [13:33:14] Testing complete. Ran 493 tests: passed: 453, skipped: 40 [13:33:14] Elapsed time: 28.862s total, 0.002s configuring, 2.526s building, 26.302s running This series is meant to be merged through the kselftest tree. Signed-off-by: Thomas Weißschuh <thomas.weissschuh(a)linutronix.de> --- Changes in v2: - Drop already applied patch - Pick up review tags - Add SPDX header - Link to v1: https://lore.kernel.org/r/20241014-kunit-loongarch-v1-0-1699b2ad6099@linutr… --- Thomas Weißschuh (3): kunit: qemu_configs: Add LoongArch config kunit: tool: Allow overriding the shutdown mode from qemu config kunit: qemu_configs: loongarch: Enable shutdown tools/testing/kunit/kunit_kernel.py | 4 +++- tools/testing/kunit/qemu_configs/loongarch.py | 21 +++++++++++++++++++++ 2 files changed, 24 insertions(+), 1 deletion(-) --- base-commit: 2d5404caa8c7bb5c4e0435f94b28834ae5456623 change-id: 20241014-kunit-loongarch-98a5b756e818 Best regards, -- Thomas Weißschuh <thomas.weissschuh(a)linutronix.de>

11 months

1
3
0 0

[PATCH v3] lib/math: Add int_sqrt test suite

by Luis Felipe Hernandez

Adds test suite for integer based square root function. The test suite is designed to verify the correctness of the int_sqrt() math library function. Signed-off-by: Luis Felipe Hernandez <luis.hernandez093(a)gmail.com> --- Changes in v2 - Add new line at the end of int_sqrt_kunit.c - Add explicit header includes for MODULE_* macros, strscpy, and ULONG_MAX Changes in v3 - Remove unnecesary new line after Kconfig entry for INT_SQRT_KUNIT_TEST - Correct int_sqrt instances with int_sqrt() in commit message and kconfig entry desc - Fix limits.h header include path --- lib/Kconfig.debug | 15 ++++++++++ lib/math/Makefile | 1 + lib/math/tests/Makefile | 1 + lib/math/tests/int_sqrt_kunit.c | 51 +++++++++++++++++++++++++++++++++ 4 files changed, 68 insertions(+) create mode 100644 lib/math/tests/int_sqrt_kunit.c diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 7312ae7c3cc5..c83f5dc9bb48 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -2993,6 +2993,21 @@ config TEST_OBJPOOL If unsure, say N. +config INT_SQRT_KUNIT_TEST + tristate "Integer square root test test" if !KUNIT_ALL_TESTS + depends on KUNIT + default KUNIT_ALL_TESTS + help + This option enables the KUnit test suite for the int_sqrt() function, + which performs square root calculation. The test suite checks + various scenarios, including edge cases, to ensure correctness. + + Enabling this option will include tests that check various scenarios + and edge cases to ensure the accuracy and reliability of the square root + function. + + If unsure, say N + endif # RUNTIME_TESTING_MENU config ARCH_USE_MEMTEST diff --git a/lib/math/Makefile b/lib/math/Makefile index 3ef11305f8d2..25bcb968b369 100644 --- a/lib/math/Makefile +++ b/lib/math/Makefile @@ -9,3 +9,4 @@ obj-$(CONFIG_INT_POW_TEST) += tests/int_pow_kunit.o obj-$(CONFIG_TEST_DIV64) += test_div64.o obj-$(CONFIG_TEST_MULDIV64) += test_mul_u64_u64_div_u64.o obj-$(CONFIG_RATIONAL_KUNIT_TEST) += rational-test.o +obj-y += tests/ diff --git a/lib/math/tests/Makefile b/lib/math/tests/Makefile index 6a169123320a..e1a79f093b2d 100644 --- a/lib/math/tests/Makefile +++ b/lib/math/tests/Makefile @@ -1,3 +1,4 @@ # SPDX-License-Identifier: GPL-2.0-only obj-$(CONFIG_INT_POW_TEST) += int_pow_kunit.o +obj-$(CONFIG_INT_SQRT_KUNIT_TEST) += int_sqrt_kunit.o diff --git a/lib/math/tests/int_sqrt_kunit.c b/lib/math/tests/int_sqrt_kunit.c new file mode 100644 index 000000000000..3590142d2012 --- /dev/null +++ b/lib/math/tests/int_sqrt_kunit.c @@ -0,0 +1,51 @@ +// SPDX-License-Identifier: GPL-2.0-only + +#include <kunit/test.h> +#include <linux/limits.h> +#include <linux/math.h> +#include <linux/module.h> +#include <linux/string.h> + +struct test_case_params { + unsigned long x; + unsigned long expected_result; + const char *name; +}; + +static const struct test_case_params params[] = { + { 0, 0, "edge-case: square root of 0" }, + { 4, 2, "perfect square: square root of 4" }, + { 81, 9, "perfect square: square root of 9" }, + { 2, 1, "non-perfect square: square root of 2" }, + { 5, 2, "non-perfect square: square root of 5"}, + { ULONG_MAX, 4294967295, "large input"}, +}; + +static void get_desc(const struct test_case_params *tc, char *desc) +{ + strscpy(desc, tc->name, KUNIT_PARAM_DESC_SIZE); +} + +KUNIT_ARRAY_PARAM(int_sqrt, params, get_desc); + +static void int_sqrt_test(struct kunit *test) +{ + const struct test_case_params *tc = (const struct test_case_params *)test->param_value; + + KUNIT_EXPECT_EQ(test, tc->expected_result, int_sqrt(tc->x)); +} + +static struct kunit_case math_int_sqrt_test_cases[] = { + KUNIT_CASE_PARAM(int_sqrt_test, int_sqrt_gen_params), + {} +}; + +static struct kunit_suite int_sqrt_test_suite = { + .name = "math-int_sqrt", + .test_cases = math_int_sqrt_test_cases, +}; + +kunit_test_suites(&int_sqrt_test_suite); + +MODULE_DESCRIPTION("math.int_sqrt KUnit test suite"); +MODULE_LICENSE("GPL"); -- 2.47.0

11 months

3
7
0 0

[PATCH net] selftests: wireguard: load nf_conntrack if it's not present

by Hangbin Liu

Some distros may not load nf_conntrack by default, which will cause subsequent nf_conntrack settings to fail. Let's load this module if it's not loaded by default. Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com> --- tools/testing/selftests/wireguard/netns.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/wireguard/netns.sh b/tools/testing/selftests/wireguard/netns.sh index 405ff262ca93..508b391e8d9a 100755 --- a/tools/testing/selftests/wireguard/netns.sh +++ b/tools/testing/selftests/wireguard/netns.sh @@ -66,6 +66,7 @@ cleanup() { orig_message_cost="$(< /proc/sys/net/core/message_cost)" trap cleanup EXIT printf 0 > /proc/sys/net/core/message_cost +lsmod | grep -q nf_conntrack || modprobe nf_conntrack ip netns del $netns0 2>/dev/null || true ip netns del $netns1 2>/dev/null || true -- 2.46.0

11 months, 1 week

2
1
0 0

[PATCH bpf v3 0/2] bpf: fix recursive lock and add test

by Jiayuan Chen

1. fix recursive lock when ebpf prog return SK_PASS. 2. add selftest to reproduce recursive lock. Note that if just the selftest merged without first patch, the test case will definitely fail, because the issue of deadlock is inevitable. --- v2->v3: fix line length reported by patchwork. (max_line_length is set to 80 in patchwork but default is 100 in kernel tree) v1->v2: 1.inspired by martin.lau to add selftest to reproduce the issue. 2. follow the community rules for patch. v1: https://lore.kernel.org/bpf/55fc6114-7e64-4b65-86d2-92cfd1e9e92f@linux.dev/… --- Jiayuan Chen (2): bpf: fix recursive lock when verdict program return SK_PASS selftests/bpf: Add some tests with sockmap SK_PASS net/core/skmsg.c | 4 +- .../selftests/bpf/prog_tests/sockmap_basic.c | 54 +++++++++++++++++++ .../bpf/progs/test_sockmap_pass_prog.c | 2 +- 3 files changed, 57 insertions(+), 3 deletions(-) -- 2.43.5

11 months, 1 week

1
2
0 0

[PATCH v4 0/3] rust: kunit: Support KUnit tests with a user-space like syntax

by David Gow

This series was originally written by José Expósito, and has been modified and updated by Matt Gilbride and myself. The original version can be found here: https://github.com/Rust-for-Linux/linux/pull/950 Add support for writing KUnit tests in Rust. While Rust doctests are already converted to KUnit tests and run, they're really better suited for examples, rather than as first-class unit tests. This series implements a series of direct Rust bindings for KUnit tests, as well as a new macro which allows KUnit tests to be written using a close variant of normal Rust unit test syntax. The only change required is replacing '#[cfg(test)]' with '#[kunit_tests(kunit_test_suite_name)]' An example test would look like: #[kunit_tests(rust_kernel_hid_driver)] mod tests { use super::*; use crate::{c_str, driver, hid, prelude::*}; use core::ptr; struct SimpleTestDriver; impl Driver for SimpleTestDriver { type Data = (); } #[test] fn rust_test_hid_driver_adapter() { let mut hid = bindings::hid_driver::default(); let name = c_str!("SimpleTestDriver"); static MODULE: ThisModule = unsafe { ThisModule::from_ptr(ptr::null_mut()) }; let res = unsafe { <hid::Adapter<SimpleTestDriver> as driver::DriverOps>::register(&mut hid, name, &MODULE) }; assert_eq!(res, Err(ENODEV)); // The mock returns -19 } } Please give this a go, and make sure I haven't broken it! There's almost certainly a lot of improvements which can be made -- and there's a fair case to be made for replacing some of this with generated C code which can use the C macros -- but this is hopefully an adequate implementation for now, and the interface can (with luck) remain the same even if the implementation changes. A few small notable missing features: - Attributes (like the speed of a test) are hardcoded to the default value. - Similarly, the module name attribute is hardcoded to NULL. In C, we use the KBUILD_MODNAME macro, but I couldn't find a way to use this from Rust which wasn't more ugly than just disabling it. - Assertions are not automatically rewritten to use KUnit assertions. --- Changes since v3: https://lore.kernel.org/linux-kselftest/20241030045719.3085147-2-davidgow@g… - The kunit_unsafe_test_suite!() macro now panic!s if the suite name is too long, triggering a compile error. (Thanks, Alice!) - The #[kunit_tests()] macro now preserves span information, so errors can be better reported. (Thanks, Boqun!) - The example tests have been updated to no longer use assert_eq!() with a constant bool argument (which triggered a clippy warning now we have the span info). Changes since v2: https://lore.kernel.org/linux-kselftest/20241029092422.2884505-1-davidgow@g… - Include missing rust/macros/kunit.rs file from v2. (Thanks Boqun!) - The kunit_unsafe_test_suite!() macro will truncate the name of the suite if it is too long. (Thanks Alice!) - The proc macro now emits an error if the suite name is too long. - We no longer needlessly use UnsafeCell<> in kunit_unsafe_test_suite!(). (Thanks Alice!) Changes since v1: https://lore.kernel.org/lkml/20230720-rustbind-v1-0-c80db349e3b5@google.com… - Rebase on top of the latest rust-next (commit 718c4069896c) - Make kunit_case a const fn, rather than a macro (Thanks Boqun) - As a result, the null terminator is now created with kernel::kunit::kunit_case_null() - Use the C kunit_get_current_test() function to implement in_kunit_test(), rather than re-implementing it (less efficiently) ourselves. Changes since the GitHub PR: - Rebased on top of kselftest/kunit - Add const_mut_refs feature This may conflict with https://lore.kernel.org/lkml/20230503090708.2524310-6-nmi@metaspace.dk/ - Add rust/macros/kunit.rs to the KUnit MAINTAINERS entry --- José Expósito (3): rust: kunit: add KUnit case and suite macros rust: macros: add macro to easily run KUnit tests rust: kunit: allow to know if we are in a test MAINTAINERS | 1 + rust/kernel/kunit.rs | 194 +++++++++++++++++++++++++++++++++++++++++++ rust/kernel/lib.rs | 1 + rust/macros/kunit.rs | 168 +++++++++++++++++++++++++++++++++++++ rust/macros/lib.rs | 29 +++++++ 5 files changed, 393 insertions(+) create mode 100644 rust/macros/kunit.rs -- 2.47.0.199.ga7371fff76-goog

11 months, 1 week

3
11
0 0

[PROBLEM] selftests/bpf/progs/test_tunnel_kern.c: 678: 41-47: ERROR: application of sizeof to pointer

by Mirsad Todorovac

Hi, all! In the linux-next tree, next-20241108, coccinelle found an error. In the line 617, ret = bpf_skb_set_tunnel_opt(skb, gopt, sizeof(local_gopt)); In the line 678, ret = bpf_skb_set_tunnel_opt(skb, gopt, sizeof(gopt)); when 592 struct local_geneve_opt local_gopt; 593 struct geneve_opt *gopt = (struct geneve_opt *) &local_gopt; and 652 struct local_geneve_opt local_gopt; 653 struct geneve_opt *gopt = (struct geneve_opt *) &local_gopt; So, in all other call to bpf_skb_set_tunnel_opt(), the third parameter is the size of the struct, not the size of the pointer: ./tools/testing/selftests/bpf/progs/test_tunnel_kern.c:193: ret = bpf_skb_set_tunnel_opt(skb, &md, sizeof(md)); ./tools/testing/selftests/bpf/progs/test_tunnel_kern.c:273: ret = bpf_skb_set_tunnel_opt(skb, &md, sizeof(md)); ./tools/testing/selftests/bpf/progs/test_tunnel_kern.c:349: ret = bpf_skb_set_tunnel_opt(skb, &md, sizeof(md)); ./tools/testing/selftests/bpf/progs/test_tunnel_kern.c:388: ret = bpf_skb_set_tunnel_opt(skb, &md, sizeof(md)); ./tools/testing/selftests/bpf/progs/test_tunnel_kern.c:617: ret = bpf_skb_set_tunnel_opt(skb, gopt, sizeof(local_gopt)); ./tools/testing/selftests/bpf/progs/test_tunnel_kern.c:678: ret = bpf_skb_set_tunnel_opt(skb, gopt, sizeof(gopt)); =========================================== 587 SEC("tc") 588 int geneve_set_tunnel(struct __sk_buff *skb) 589 { 590 int ret; 591 struct bpf_tunnel_key key; 592 struct local_geneve_opt local_gopt; 593 struct geneve_opt *gopt = (struct geneve_opt *) &local_gopt; 594 595 __builtin_memset(&key, 0x0, sizeof(key)); 596 key.remote_ipv4 = 0xac100164; /* 172.16.1.100 */ 597 key.tunnel_id = 2; 598 key.tunnel_tos = 0; 599 key.tunnel_ttl = 64; 600 601 __builtin_memset(gopt, 0x0, sizeof(local_gopt)); 602 gopt->opt_class = bpf_htons(0x102); /* Open Virtual Networking (OVN) */ 603 gopt->type = 0x08; 604 gopt->r1 = 0; 605 gopt->r2 = 0; 606 gopt->r3 = 0; 607 gopt->length = 2; /* 4-byte multiple */ 608 *(int *) &gopt->opt_data = bpf_htonl(0xdeadbeef); 609 610 ret = bpf_skb_set_tunnel_key(skb, &key, sizeof(key), 611 BPF_F_ZERO_CSUM_TX); 612 if (ret < 0) { 613 log_err(ret); 614 return TC_ACT_SHOT; 615 } 616 617 → ret = bpf_skb_set_tunnel_opt(skb, gopt, sizeof(local_gopt)); 618 if (ret < 0) { 619 log_err(ret); 620 return TC_ACT_SHOT; 621 } 622 623 return TC_ACT_OK; 624 } 648 SEC("tc") 649 int ip6geneve_set_tunnel(struct __sk_buff *skb) 650 { 651 struct bpf_tunnel_key key; 652 struct local_geneve_opt local_gopt; 653 struct geneve_opt *gopt = (struct geneve_opt *) &local_gopt; 654 int ret; 655 656 __builtin_memset(&key, 0x0, sizeof(key)); 657 key.remote_ipv6[3] = bpf_htonl(0x11); /* ::11 */ 658 key.tunnel_id = 22; 659 key.tunnel_tos = 0; 660 key.tunnel_ttl = 64; 661 662 ret = bpf_skb_set_tunnel_key(skb, &key, sizeof(key), 663 BPF_F_TUNINFO_IPV6); 664 if (ret < 0) { 665 log_err(ret); 666 return TC_ACT_SHOT; 667 } 668 669 __builtin_memset(gopt, 0x0, sizeof(local_gopt)); 670 gopt->opt_class = bpf_htons(0x102); /* Open Virtual Networking (OVN) */ 671 gopt->type = 0x08; 672 gopt->r1 = 0; 673 gopt->r2 = 0; 674 gopt->r3 = 0; 675 gopt->length = 2; /* 4-byte multiple */ 676 *(int *) &gopt->opt_data = bpf_htonl(0xfeedbeef); 677 678 → ret = bpf_skb_set_tunnel_opt(skb, gopt, sizeof(gopt)); 679 if (ret < 0) { 680 log_err(ret); 681 return TC_ACT_SHOT; 682 } 683 684 return TC_ACT_OK; 685 } SOLUTION: Fixes: 5ddafcc377f98 ("selftests/bpf: Fix a few tests for GCC related warnings.") ------------------ diff --git a/tools/testing/selftests/bpf/progs/test_tunnel_kern.c b/tools/testing/selftests/bpf/progs/test_tunnel_kern.c index 32127f1cd687..b53d367451b2 100644 --- a/tools/testing/selftests/bpf/progs/test_tunnel_kern.c +++ b/tools/testing/selftests/bpf/progs/test_tunnel_kern.c @@ -675,7 +675,7 @@ int ip6geneve_set_tunnel(struct __sk_buff *skb) gopt->length = 2; /* 4-byte multiple */ *(int *) &gopt->opt_data = bpf_htonl(0xfeedbeef); - ret = bpf_skb_set_tunnel_opt(skb, gopt, sizeof(gopt)); + ret = bpf_skb_set_tunnel_opt(skb, gopt, sizeof(local_gopt)); if (ret < 0) { log_err(ret); return TC_ACT_SHOT; -- Best regards, MT

11 months, 1 week

1
0
0 0

[PATCH] kunit: skb: use "gfp" variable instead of hardcoding GFP_KERNEL

by Dan Carpenter

The intent here was clearly to use the gfp variable flags instead of hardcoding GFP_KERNEL. All the callers pass GFP_KERNEL as the gfp flags so this doesn't affect runtime. Fixes: b3231d353a51 ("kunit: add a convenience allocation wrapper for SKBs") Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> --- include/kunit/skbuff.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/kunit/skbuff.h b/include/kunit/skbuff.h index 44d12370939a..345e1e8f0312 100644 --- a/include/kunit/skbuff.h +++ b/include/kunit/skbuff.h @@ -29,7 +29,7 @@ static void kunit_action_kfree_skb(void *p) static inline struct sk_buff *kunit_zalloc_skb(struct kunit *test, int len, gfp_t gfp) { - struct sk_buff *res = alloc_skb(len, GFP_KERNEL); + struct sk_buff *res = alloc_skb(len, gfp); if (!res || skb_pad(res, len)) return NULL; -- 2.45.2

11 months, 1 week

3
2
0 0

[PATCH net-next v8 0/6] Suspend IRQs during application busy periods

by Joe Damato

Greetings: Welcome to v8, see changelog below. This revision is a quick follow-up to v7 and only drops the unneeded exports in patch 2. No other changes. This series introduces a new mechanism, IRQ suspension, which allows network applications using epoll to mask IRQs during periods of high traffic while also reducing tail latency (compared to existing mechanisms, see below) during periods of low traffic. In doing so, this balances CPU consumption with network processing efficiency. Martin Karsten (CC'd) and I have been collaborating on this series for several months and have appreciated the feedback from the community on our RFC [1]. We've updated the cover letter and kernel documentation in an attempt to more clearly explain how this mechanism works, how applications can use it, and how it compares to existing mechanisms in the kernel. I briefly mentioned this idea at netdev conf 2024 (for those who were there) and Martin described this idea in an earlier paper presented at Sigmetrics 2024 [2]. ~ The short explanation (TL;DR) We propose adding a new napi config parameter: irq_suspend_timeout to help balance CPU usage and network processing efficiency when using IRQ deferral and napi busy poll. If this parameter is set to a non-zero value *and* a user application has enabled preferred busy poll on a busy poll context (via the EPIOCSPARAMS ioctl introduced in commit 18e2bf0edf4d ("eventpoll: Add epoll ioctl for epoll_params")), then application calls to epoll_wait for that context will cause device IRQs and softirq processing to be suspended as long as epoll_wait successfully retrieves data from the NAPI. Each time data is retrieved, the irq_suspend_timeout is deferred. If/when network traffic subsides and epoll_wait returns no data, IRQ suspension is immediately reverted back to the existing napi_defer_hard_irqs and gro_flush_timeout mechanism which was introduced in commit 6f8b12d661d0 ("net: napi: add hard irqs deferral feature")). The irq_suspend_timeout serves as a safety mechanism. If userland takes a long time processing data, irq_suspend_timeout will fire and restart normal NAPI processing. For a more in depth explanation, please continue reading. ~ Comparison with existing mechanisms Interrupt mitigation can be accomplished in napi software, by setting napi_defer_hard_irqs and gro_flush_timeout, or via interrupt coalescing in the NIC. This can be quite efficient, but in both cases, a fixed timeout (or packet count) needs to be configured. However, a fixed timeout cannot effectively support both low- and high-load situations: At low load, an application typically processes a few requests and then waits to receive more input data. In this scenario, a large timeout will cause unnecessary latency. At high load, an application typically processes many requests before being ready to receive more input data. In this case, a small timeout will likely fire prematurely and trigger irq/softirq processing, which interferes with the application's execution. This causes overhead, most likely due to cache contention. While NICs attempt to provide adaptive interrupt coalescing schemes, these cannot properly take into account application-level processing. An alternative packet delivery mechanism is busy-polling, which results in perfect alignment of application processing and network polling. It delivers optimal performance (throughput and latency), but results in 100% cpu utilization and is thus inefficient for below-capacity workloads. We propose to add a new packet delivery mode that properly alternates between busy polling and interrupt-based delivery depending on busy and idle periods of the application. During a busy period, the system operates in busy-polling mode, which avoids interference. During an idle period, the system falls back to interrupt deferral, but with a small timeout to avoid excessive latencies. This delivery mode can also be viewed as an extension of basic interrupt deferral, but alternating between a small and a very large timeout. This delivery mode is efficient, because it avoids softirq execution interfering with application processing during busy periods. It can be used with blocking epoll_wait to conserve cpu cycles during idle periods. The effect of alternating between busy and idle periods is that performance (throughput and latency) is very close to full busy polling, while cpu utilization is lower and very close to interrupt mitigation. ~ Usage details IRQ suspension is introduced via a per-NAPI configuration parameter that controls the maximum time that IRQs can be suspended. Here's how it is intended to work: - The user application (or system administrator) uses the netdev-genl netlink interface to set the pre-existing napi_defer_hard_irqs and gro_flush_timeout NAPI config parameters to enable IRQ deferral. - The user application (or system administrator) sets the proposed irq_suspend_timeout parameter via the netdev-genl netlink interface to a larger value than gro_flush_timeout to enable IRQ suspension. - The user application issues the existing epoll ioctl to set the prefer_busy_poll flag on the epoll context. - The user application then calls epoll_wait to busy poll for network events, as it normally would. - If epoll_wait returns events to userland, IRQs are suspended for the duration of irq_suspend_timeout. - If epoll_wait finds no events and the thread is about to go to sleep, IRQ handling using napi_defer_hard_irqs and gro_flush_timeout is resumed. As long as epoll_wait is retrieving events, IRQs (and softirq processing) for the NAPI being polled remain disabled. When network traffic reduces, eventually a busy poll loop in the kernel will retrieve no data. When this occurs, regular IRQ deferral using gro_flush_timeout for the polled NAPI is re-enabled. Unless IRQ suspension is continued by subsequent calls to epoll_wait, it automatically times out after the irq_suspend_timeout timer expires. Regular deferral is also immediately re-enabled when the epoll context is destroyed. ~ Usage scenario The target scenario for IRQ suspension as packet delivery mode is a system that runs a dominant application with substantial network I/O. The target application can be configured to receive input data up to a certain batch size (via epoll_wait maxevents parameter) and this batch size determines the worst-case latency that application requests might experience. Because packet delivery is suspended during the target application's processing, the batch size also determines the worst-case latency of concurrent applications using the same RX queue(s). gro_flush_timeout should be set as small as possible, but large enough to make sure that a single request is likely not being interfered with. irq_suspend_timeout is largely a safety mechanism against misbehaving applications. It should be set large enough to cover the processing of an entire application batch, i.e., the factor between gro_flush_timeout and irq_suspend_timeout should roughly correspond to the maximum batch size that the target application would process in one go. ~ Important call out in the implementation - Enabling per epoll-context preferred busy poll will now effectively lead to a nonblocking iteration through napi_busy_loop, even when busy_poll_usecs is 0. See patch 4. ~ Benchmark configs & descriptions The changes were benchmarked with memcached [3] using the benchmarking tool mutilate [4]. To facilitate benchmarking, a small patch [5] was applied to memcached 1.6.29 to allow setting per-epoll context preferred busy poll and other settings via environment variables. Another small patch [6] was applied to libevent to enable full busy-polling. Multiple scenarios were benchmarked as described below and the scripts used for producing these results can be found on github [7] (note: all scenarios use NAPI-based traffic splitting via SO_INCOMING_ID by passing -N to memcached): - base: - no other options enabled - deferX: - set defer_hard_irqs to 100 - set gro_flush_timeout to X,000 - napibusy: - set defer_hard_irqs to 100 - set gro_flush_timeout to 200,000 - enable busy poll via the existing ioctl (busy_poll_usecs = 64, busy_poll_budget = 64, prefer_busy_poll = true) - fullbusy: - set defer_hard_irqs to 100 - set gro_flush_timeout to 5,000,000 - enable busy poll via the existing ioctl (busy_poll_usecs = 1000, busy_poll_budget = 64, prefer_busy_poll = true) - change memcached's nonblocking epoll_wait invocation (via libevent) to using a 1 ms timeout - suspend0: - set defer_hard_irqs to 0 - set gro_flush_timeout to 0 - set irq_suspend_timeout to 20,000,000 - enable busy poll via the existing ioctl (busy_poll_usecs = 0, busy_poll_budget = 64, prefer_busy_poll = true) - suspendX: - set defer_hard_irqs to 100 - set gro_flush_timeout to X,000 - set irq_suspend_timeout to 20,000,000 - enable busy poll via the existing ioctl (busy_poll_usecs = 0, busy_poll_budget = 64, prefer_busy_poll = true) ~ Benchmark results Tested on: Single socket AMD EPYC 7662 64-Core Processor Hyperthreading disabled 4 NUMA Zones (NPS=4) 16 CPUs per NUMA zone (64 cores total) 2 x Dual port 100gbps Mellanox Technologies ConnectX-5 Ex EN NIC The test machine is configured such that a single interface has 8 RX queues. The queues' IRQs and memcached are pinned to CPUs that are NUMA-local to the interface which is under test. The NIC's interrupt coalescing configuration is left at boot-time defaults. Results: Results are shown below. The mechanism added by this series is represented by the 'suspend' cases. Data presented shows a summary over nearly 10 runs of each test case [8] using the scripts on github [7]. For latency, the median is shown. For throughput and CPU utilization, the average is shown. The results also include cycles-per-query (cpq) and instruction-per-query (ipq) metrics, following the methodology proposed in [2], to augment the CPU utilization numbers, which could be skewed due to frequency scaling. We find that this does not appear to be the case as CPU utilization and low-level metrics show similar trends. These results were captured using the scripts on github [7] to illustrate how this approach compares with other pre-existing mechanisms. This data is not to be interpreted as scientific data captured in a fully isolated lab setting, but instead as best effort, illustrative information comparing and contrasting tradeoffs. The absolute QPS results shift between submissions, but the relative differences are equivalent. As patches are rebased, several factors likely influence overall performance. Compare: - Throughput (MAX) and latencies of base vs suspend. - CPU usage of napibusy and fullbusy during lower load (200K, 400K for example) vs suspend. - Latency of the defer variants vs suspend as timeout and load increases. - suspend0, which sets defer_hard_irqs and gro_flush_timeout to 0, has nearly the same performance as the base case (this is FAQ item #1). The overall takeaway is that the suspend variants provide a superior combination of high throughput, low latency, and low cpu utilization compared to all other variants. Each of the suspend variants works very well, but some fine-tuning between latency and cpu utilization is still possible by tuning the small timeout (gro_flush_timeout). Note: we've reorganized the results to make comparison among testcases with the same load easier. testcase load qps avglat 95%lat 99%lat cpu cpq ipq base 200K 199946 112 239 416 26 12973 11343 defer10 200K 199971 54 124 142 29 19412 17460 defer20 200K 199986 60 130 153 26 15644 14095 defer50 200K 200025 79 144 182 23 12122 11632 defer200 200K 199999 164 254 309 19 8923 9635 fullbusy 200K 199998 46 118 133 100 43658 23133 napibusy 200K 199983 100 237 277 56 24840 24716 suspend0 200K 200020 105 249 432 30 14264 11796 suspend10 200K 199950 53 123 141 32 19518 16903 suspend20 200K 200037 58 126 151 30 16426 14736 suspend50 200K 199961 73 136 177 26 13310 12633 suspend200 200K 199998 149 251 306 21 9566 10203 testcase load qps avglat 95%lat 99%lat cpu cpq ipq base 400K 400014 139 269 707 41 9476 9343 defer10 400K 400016 59 133 166 53 13991 12989 defer20 400K 399952 67 140 172 47 12063 11644 defer50 400K 400007 87 162 198 39 9384 9880 defer200 400K 399979 181 274 330 31 7089 8430 fullbusy 400K 399987 50 123 156 100 21827 16037 napibusy 400K 400014 76 222 272 83 18185 16529 suspend0 400K 400015 127 350 776 47 10699 9603 suspend10 400K 400023 57 129 164 54 13758 13178 suspend20 400K 400043 62 135 169 49 12071 11826 suspend50 400K 400071 76 149 186 42 10011 10301 suspend200 400K 399961 154 269 327 34 7827 8774 testcase load qps avglat 95%lat 99%lat cpu cpq ipq base 600K 599951 149 266 574 61 9265 8876 defer10 600K 600006 71 147 203 76 11866 10936 defer20 600K 600123 76 152 203 66 10430 10342 defer50 600K 600162 95 172 217 54 8526 9142 defer200 600K 599942 200 301 357 46 6977 8212 fullbusy 600K 599990 55 127 177 100 14551 13983 napibusy 600K 600035 63 160 250 96 13937 14140 suspend0 600K 599903 127 320 732 68 10166 8963 suspend10 600K 599908 63 137 192 69 10902 11100 suspend20 600K 599961 66 141 194 65 9976 10370 suspend50 600K 599973 80 159 204 57 8678 9381 suspend200 600K 600010 157 277 346 48 7133 8381 testcase load qps avglat 95%lat 99%lat cpu cpq ipq base 800K 800039 181 300 536 87 9585 8304 defer10 800K 800038 181 530 939 96 10564 8970 defer20 800K 800029 112 225 329 90 10056 8935 defer50 800K 799999 120 208 296 82 9234 8562 defer200 800K 800066 227 338 401 63 7117 8129 fullbusy 800K 800040 61 134 190 100 10913 12608 napibusy 800K 799944 64 141 214 99 10828 12588 suspend0 800K 799911 126 248 509 85 9346 8498 suspend10 800K 800006 69 143 200 83 9410 9845 suspend20 800K 800120 74 150 207 78 8786 9454 suspend50 800K 799989 87 168 224 71 7946 8833 suspend200 800K 799987 160 292 357 62 6923 8229 testcase load qps avglat 95%lat 99%lat cpu cpq ipq base 1000K 906879 4079 5751 6216 98 9496 7904 defer10 1000K 860849 3643 6274 6730 99 10040 8676 defer20 1000K 896063 3298 5840 6349 98 9620 8237 defer50 1000K 919782 2962 5513 5807 97 9284 7951 defer200 1000K 970941 3059 5348 5984 95 8593 7959 fullbusy 1000K 999950 70 150 207 100 8732 10777 napibusy 1000K 999996 78 154 223 100 8722 10656 suspend0 1000K 949706 2666 5770 6660 99 9071 8046 suspend10 1000K 1000024 80 160 220 92 8137 9035 suspend20 1000K 1000059 83 165 226 89 7850 8804 suspend50 1000K 999955 95 180 240 84 7411 8459 suspend200 1000K 999914 163 299 366 77 6833 8078 testcase load qps avglat 95%lat 99%lat cpu cpq ipq base MAX 1037654 4184 5453 5810 100 8411 7938 defer10 MAX 905607 4840 6151 6380 100 9639 8431 defer20 MAX 986463 4455 5594 5796 100 8848 8110 defer50 MAX 1077030 4000 5073 5299 100 8104 7920 defer200 MAX 1040728 4152 5385 5765 100 8379 7849 fullbusy MAX 1247536 3518 3935 3984 100 6998 7930 napibusy MAX 1136310 3799 7756 9964 100 7670 7877 suspend0 MAX 1057509 4132 5724 6185 100 8253 7918 suspend10 MAX 1215147 3580 3957 4041 100 7185 7944 suspend20 MAX 1216469 3576 3953 3988 100 7175 7950 suspend50 MAX 1215871 3577 3961 4075 100 7181 7949 suspend200 MAX 1216882 3556 3951 3988 100 7175 7955 ~ FAQ - Why is a new parameter needed? Does irq_suspend_timeout override gro_flush_timeout? Using the suspend mechanism causes the system to alternate between polling mode and irq-driven packet delivery. During busy periods, irq_suspend_timeout overrides gro_flush_timeout and keeps the system busy polling, but when epoll finds no events, the setting of gro_flush_timeout and napi_defer_hard_irqs determine the next step. There are essentially three possible loops for network processing and packet delivery: 1) hardirq -> softirq -> napi poll; basic interrupt delivery 2) timer -> softirq -> napi poll; deferred irq processing 3) epoll -> busy-poll -> napi poll; busy looping Loop 2 can take control from Loop 1, if gro_flush_timeout and napi_defer_hard_irqs are set. If gro_flush_timeout and napi_defer_hard_irqs are set, Loops 2 and 3 "wrestle" with each other for control. During busy periods, irq_suspend_timeout is used as timer in Loop 2, which essentially tilts this in favour of Loop 3. If gro_flush_timeout and napi_defer_hard_irqs are not set, Loop 3 cannot take control from Loop 1. Therefore, setting gro_flush_timeout and napi_defer_hard_irqs is the recommended usage, because otherwise setting irq_suspend_timeout might not have any discernible effect. This is shown in the results above: compare suspend0 with the base case. Note that the lack of napi_defer_hard_irqs and gro_flush_timeout produce similar results for both, which encourages the use of napi_defer_hard_irqs and gro_flush_timeout in addition to irq_suspend_timeout. - Can the new timeout value be threaded through the new epoll ioctl ? It is possible, but presents challenges for userspace. User applications must ensure that the file descriptors added to epoll contexts have the same NAPI ID to support busy polling. An epoll context is not permanently tied to any particular NAPI ID. So, a user application could decide to clear the file descriptors from the context and add a new set of file descriptors with a different NAPI ID to the context. Busy polling would work as expected, but the meaning of the suspend timeout becomes ambiguous because IRQs are not inherently associated with epoll contexts, but rather with the NAPI. The user program would need to reissue the ioctl to set the irq_suspend_timeout, but the napi_defer_hard_irqs and gro_flush_timeout settings would come from the NAPI's napi_config (which are set either by sysfs or by netlink). Such an interface seems awkard to use from a user perspective. Further, IRQs are related to NAPIs, which is why they are stored in the napi_config space. Putting the irq_suspend_timeout in the epoll context while other IRQ deferral mechanisms remain in the NAPI's napi_config space seems like an odd design choice. We've opted to keep all of the IRQ deferral parameters together and place the irq_suspend_timeout in napi_config. This has nice benefits for userspace: if a user app were to remove all file descriptors from an epoll context and add new file descriptors with a new NAPI ID, the correct suspend timeout for that NAPI ID would be used automatically without the user application needing to do anything (like re-issuing an ioctl, for example). All IRQ deferral related parameters are in one place and can all be set the same way: with netlink. - Can irq suspend be built by combining NIC coalescing and gro_flush_timeout ? No. The problem is that the long timeout must engage if and only if prefer-busy is active. When using NIC coalescing for the short timeout (without napi_defer_hard_irqs/gro_flush_timeout), an interrupt after an idle period will trigger softirq, which will run napi polling. At this point, prefer-busy is not active, so NIC interrupts would be re-enabled. Then it is not possible for the longer timeout to interject to switch control back to polling. In other words, only by using the software timer for the short timeout, it is possible to extend the timeout without having to reprogram the NIC timer or reach down directly and disable interrupts. Using gro_flush_timeout for the long timeout also has problems, for the same underlying reason. In the current napi implementation, gro_flush_timeout is not tied to prefer-busy. We'd either have to change that and in the process modify the existing deferral mechanism, or introduce a state variable to determine whether gro_flush_timeout is used as long timeout for irq suspend or whether it is used for its default purpose. In an earlier version, we did try something similar to the latter and made it work, but it ends up being a lot more convoluted than our current proposal. - Isn't it already possible to combine busy looping with irq deferral? Yes, in fact enabling irq deferral via napi_defer_hard_irqs and gro_flush_timeout is a precondition for prefer_busy_poll to have an effect. If the application also uses a tight busy loop with essentially nonblocking epoll_wait (accomplished with a very short timeout parameter), this is the fullbusy case shown in the results. An application using blocking epoll_wait is shown as the napibusy case in the results. It's a hybrid approach that provides limited latency benefits compared to the base case and plain irq deferral, but not as good as fullbusy or suspend. ~ Special thanks Several people were involved in earlier stages of the development of this mechanism whom we'd like to thank: - Peter Cai (CC'd), for the initial kernel patch and his contributions to the paper. - Mohammadamin Shafie (CC'd), for testing various versions of the kernel patch and providing helpful feedback. Thanks, Martin and Joe [1]: https://lore.kernel.org/netdev/20240812125717.413108-1-jdamato@fastly.com/ [2]: https://doi.org/10.1145/3626780 [3]: https://github.com/memcached/memcached/blob/master/doc/napi_ids.txt [4]: https://github.com/leverich/mutilate [5]: https://raw.githubusercontent.com/martinkarsten/irqsuspend/main/patches/mem… [6]: https://raw.githubusercontent.com/martinkarsten/irqsuspend/main/patches/lib… [7]: https://github.com/martinkarsten/irqsuspend [8]: https://github.com/martinkarsten/irqsuspend/tree/main/results v8: - Update patch 2 to drop the exports, as requested by Jakub. v7: https://lore.kernel.org/netdev/20241108023912.98416-1-jdamato@fastly.com/ - Jakub noted that patch 2 adds unnecessary complexity by checking the suspend timeout in the NAPI loop. This makes the code more complicated and difficult to reason about. He's right; we've dropped patch 2 which simplifies this series. - Updated the cover letter with a full re-run of all test cases. - Updated FAQ #2. v6: https://lore.kernel.org/netdev/20241104215542.215919-1-jdamato@fastly.com/ - Updated the cover letter with a full re-run of all test cases, including a new case suspend0, as requested by Sridhar previously. - Updated the kernel documentation in patch 7 as suggested by Bagas Sanjaya, which improved the htmldoc output. v5: https://lore.kernel.org/netdev/20241103052421.518856-1-jdamato@fastly.com/ - Adjusted patch 5 to only suspend IRQs when ep_send_events returns a positive return value. This issue was pointed out by Hillf Danton. - Updated the commit message of patch 6 which still mentioned netcat, despite the code being updated in v4 to replace it with socat and fixed misspelling of netdevsim. - Fixed a minor typo in patch 7 and removed an unnecessary paragraph. - Added Sridhar Samudrala's Reviewed-by to patch 1-5 and 7. v4: https://lore.kernel.org/netdev/20241102005214.32443-1-jdamato@fastly.com/ - Added a new FAQ item to cover letter. - Updated patch 6 to use socat instead of nc in busy_poll_test.sh and updated busy_poller.c to use netlink directly to configure napi params. - Updated the kernel documentation in patch 7 to include more details. - Dropped Stanislav's Acked-by and Bagas' Reviewed-by from patch 7 since the documentation was updated. v3: https://lore.kernel.org/netdev/20241101004846.32532-1-jdamato@fastly.com/ - Added Stanislav Fomichev's Acked-by to every patch except the newly added selftest. - Added Bagas Sanjaya's Reviewed-by to the documentation patch. - Fixed the commit message of patch 2 to remove a reference to the now non-existent sysfs setting. - Added a self test which tests both "regular" busy poll and busy poll with suspend enabled. This was added as patch 6 as requested by Paolo. netdevsim was chosen instead of veth due to netdevsim's pre-existing support for netdev-genl. See the commit message of patch 6 for more details. v2: https://lore.kernel.org/bpf/20241021015311.95468-1-jdamato@fastly.com/ - Cover letter updated, including a re-run of test data. - Patch 1 rewritten to use netdev-genl instead of sysfs. - Patch 3 updated with a comment added to napi_resume_irqs. - Patch 4 rebased to apply now that commit b9ca079dd6b0 ("eventpoll: Annotate data-race of busy_poll_usecs") has been picked up from VFS. - Patch 6 updated the kernel documentation. rfc -> v1: - Cover letter updated to include more details. - Patch 1 updated to remove the documentation added. This was moved to patch 6 with the rest of the docs (see below). - Patch 5 updated to fix an error uncovered by the kernel build robot. See patch 5's changelog for more details. - Patch 6 added which updates kernel documentation. Joe Damato (2): selftests: net: Add busy_poll_test docs: networking: Describe irq suspension Martin Karsten (4): net: Add napi_struct parameter irq_suspend_timeout net: Add control functions for irq suspension eventpoll: Trigger napi_busy_loop, if prefer_busy_poll is set eventpoll: Control irq suspension for prefer_busy_poll Documentation/netlink/specs/netdev.yaml | 7 + Documentation/networking/napi.rst | 170 ++++++++- fs/eventpoll.c | 36 +- include/linux/netdevice.h | 2 + include/net/busy_poll.h | 3 + include/uapi/linux/netdev.h | 1 + net/core/dev.c | 39 +++ net/core/dev.h | 25 ++ net/core/netdev-genl-gen.c | 5 +- net/core/netdev-genl.c | 12 + tools/include/uapi/linux/netdev.h | 1 + tools/testing/selftests/net/.gitignore | 1 + tools/testing/selftests/net/Makefile | 3 +- tools/testing/selftests/net/busy_poll_test.sh | 164 +++++++++ tools/testing/selftests/net/busy_poller.c | 328 ++++++++++++++++++ 15 files changed, 790 insertions(+), 7 deletions(-) create mode 100755 tools/testing/selftests/net/busy_poll_test.sh create mode 100644 tools/testing/selftests/net/busy_poller.c base-commit: dc7c381bb8649e3701ed64f6c3e55316675904d7 -- 2.25.1

11 months, 1 week

2
7
0 0

[PATCH] selftests/mm: Define PKEY_UNRESTRICTED for pkey_sighandler_tests

by Kevin Brodsky

Commit 6e182dc9f268 ("selftests/mm: Use generic pkey register manipulation") makes use of PKEY_UNRESTRICTED in pkey_sighandler_tests. The macro has been proposed for addition to uapi headers [1], but the patch hasn't landed yet. Define PKEY_UNRESTRICTED in pkey-helpers.h for the time being to fix the build. [1] https://lore.kernel.org/all/20241028090715.509527-2-yury.khrustalev@arm.com/ Fixes: 6e182dc9f268 ("selftests/mm: Use generic pkey register manipulation") Reported-by: Aishwarya TCV <aishwarya.tcv(a)arm.com> Signed-off-by: Kevin Brodsky <kevin.brodsky(a)arm.com> --- Based on arm64 for-next/pkey-signal (49f59573e9e0). --- tools/testing/selftests/mm/pkey-helpers.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tools/testing/selftests/mm/pkey-helpers.h b/tools/testing/selftests/mm/pkey-helpers.h index 9ab6a3ee153b..319f5b6b7132 100644 --- a/tools/testing/selftests/mm/pkey-helpers.h +++ b/tools/testing/selftests/mm/pkey-helpers.h @@ -112,6 +112,10 @@ void record_pkey_malloc(void *ptr, long size, int prot); #define PKEY_MASK (PKEY_DISABLE_ACCESS | PKEY_DISABLE_WRITE) #endif +#ifndef PKEY_UNRESTRICTED +#define PKEY_UNRESTRICTED 0x0 +#endif + #ifndef set_pkey_bits static inline u64 set_pkey_bits(u64 reg, int pkey, u64 flags) { -- 2.43.0

11 months, 1 week

3
5
0 0

[PATCH] selftests: netfilter: Fix the bug of missing return values

by guanjing

Fixed the bug of some functions were missing return values. Fixes: eff3c558bb7e ("netfilter: ctnetlink: support filtering by zone") Signed-off-by: Guan Jing <guanjing(a)cmss.chinamobile.com> --- .../testing/selftests/net/netfilter/conntrack_dump_flush.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/tools/testing/selftests/net/netfilter/conntrack_dump_flush.c b/tools/testing/selftests/net/netfilter/conntrack_dump_flush.c index 254ff03297f0..5f827e10717d 100644 --- a/tools/testing/selftests/net/netfilter/conntrack_dump_flush.c +++ b/tools/testing/selftests/net/netfilter/conntrack_dump_flush.c @@ -43,6 +43,8 @@ static int build_cta_tuple_v4(struct nlmsghdr *nlh, int type, mnl_attr_nest_end(nlh, nest_proto); mnl_attr_nest_end(nlh, nest); + + return 0; } static int build_cta_tuple_v6(struct nlmsghdr *nlh, int type, @@ -71,6 +73,8 @@ static int build_cta_tuple_v6(struct nlmsghdr *nlh, int type, mnl_attr_nest_end(nlh, nest_proto); mnl_attr_nest_end(nlh, nest); + + return 0; } static int build_cta_proto(struct nlmsghdr *nlh) @@ -90,6 +94,8 @@ static int build_cta_proto(struct nlmsghdr *nlh) mnl_attr_nest_end(nlh, nest_proto); mnl_attr_nest_end(nlh, nest); + + return 0; } static int conntrack_data_insert(struct mnl_socket *sock, struct nlmsghdr *nlh, -- 2.33.0

11 months, 1 week

1
0
0 0

Some thoughts on Linux benchmarks results & processing

by Konstantin Belov

Hello colleagues, Following up on Tim Bird's presentation "Adding benchmarks results support to KTAP/kselftest", I would like to share some thoughts on kernel benchmarking and kernel performance evaluation. Tim suggested sharing these comments with the wider kselftest community for discussion. The topic of performance evaluation is obviously extremely complex, so I’ve organised my comments into several paragraphs, each of which focuses on a specific aspect. This should make it easier to follow and understand the key points, such as metrics, reference values, results data lake, interpretation of contradictory results, system profiles, analysis and methodology. # Metrics A few remarks on benchmark metrics which were called “values” in the original presentation: - Metrics must be accompanied by standardised units. This standardisation ensures consistency across different tests and environments, simplifying accurate comparisons and analysis. - Each metric should be clearly labelled with its nature or kind (throughput, speed, latency, etc). This classification is essential for proper interpretation of the results and prevents misunderstandings that could lead to incorrect conclusions. - Presentation contains "May also include allowable variance", but variance must be included into the analysis as we deal with statistical calculations and multiple randomised values. - I would like to note that other statistical parameters are also worth including into comparison, like confidence levels, sample size and so on. # Reference Values The concept of "reference values" introduced in the slides could be significantly enhanced by implementing a collaborative, transparent system for data collection and validation. This system could operate as follows: - Data Collection: Any user could submit benchmark results to a centralised and public repository. This would allow for a diverse range of hardware configurations and use cases to be represented. - Vendor Validation: Hardware vendors would have the opportunity to review submitted results pertaining to their products. They could then mark certain results as "Vendor Approved," indicating that the results align with their own testing and expectations. - Community Review: The broader community of users and experts could also review and vote on submitted results. Results that receive substantial positive feedback could be marked as "Community Approved," providing an additional layer of validation. - Automated Validation: Reference values must be checked, validated and supported by multiple sources. This can be done only in an automatic way as those processes are time consuming and require extreme attention to details. - Transparency: All submitted results would need to be accompanied by detailed information about the testing environment, hardware specifications, and methodology used. This would ensure reproducibility and allow others to understand the context of each result. - Trust Building: The combination of vendor and community approval would help establish trust in the reference values. It would mitigate concerns about marketing bias and provide a more reliable basis for performance comparisons. - Accessibility: The system would be publicly accessible, allowing anyone to reference and utilise this data in their own testing and analysis. Implementation of such a system would require careful consideration of governance and funding. A community-driven, non-profit organisation sponsored by multiple stakeholders could be an appropriate model. This structure would help maintain neutrality and avoid potential conflicts of interest. While the specifics of building and managing such a system would need further exploration, this approach could significantly improve the reliability and usefulness of reference values in benchmark testing. It would foster a more collaborative and transparent environment for performance evaluation in the Linux ecosystem as well as attract interested vendors to submit and review results. I’m not very informed about the current state of the community in this field, but I’m sure you know better how exactly this can be done. # Results Data Lake Along with reference values it’s important to collect results on a regular basis as the kernel evolves so results must follow this evolution as well. To do this cloud-based data lake is needed (a self-hosted system will be too expensive from my point of view). This data lake should be able to collect and process incoming data as well as to serve reference values for users. Data processing flow should be quite standard: Collection -> Parsing + Enhancement -> Storage -> Analysis -> Serving. Tim proposed to use file names for reference files, I would like to note that such approach could fail pretty fast if system will collect more and more data and there will rise a need to have more granular and detailed features to identify reference results and this can lead to very long filenames, which will be hard to use. I propose to use UUID4-based identification, which provides very low chances for collision. Those IDs will be keys in the database with all information required for clear identification of relevant results and corresponding details. Moreover this approach can be easily extended on the database side if more data is needed. Yes, UUID4 is not human-readable, but do we need such an option if we have tools, which can provide a better interface? For example, this could be something like: --- request: results-cli search -b "Test Suite D" -v "v1.2.3" -o "Ubuntu 22.04" -t "baseline" -m "response_time>100" response: [ { "id": "550e8400-e29b-41d4-a716-446655440005", "benchmark": "Test Suite A", "version": "v1.2.3", "target_os": "Ubuntu 22.04", "metrics": { "cpu_usage": 70.5, "memory_usage": 2048, "response_time": 120 }, "tags": ["baseline", "v1.0"], "created_at": "2024-10-25T10:00:00Z" }, ... ] --- or request: results-cli search "<Domain-Specific-Language-Query>" response: [ {}, {}, {}...] --- or request: results-cli get 550e8400-e29b-41d4-a716-446655440005 response: { "id": "550e8400-e29b-41d4-a716-446655440005", "benchmark": "Test Suite A", "version": "v1.2.3", "target_os": "Ubuntu 22.04", "metrics": { "cpu_usage": 70.5, "memory_usage": 2048, "response_time": 120 }, "tags": ["baseline", "v1.0"], "created_at": "2024-10-25T10:00:00Z" } --- or request: curl -X POST http://api.example.com/references/search \ -d '{ "query": "benchmark = \"Test Suite A\" AND (version >= \"v1.2\" OR tag IN [\"baseline\", \"regression\"]) AND cpu_usage > 60" }' ... --- Another point of use DB-based approach is the following: in case when a user works with particular hardware and/or would like to use a reference he/she does not need a full database with all collected reference values, but only a small slice of it. This slice can be downloaded from public repo or accessed via API. # Large results dataset If we collect a large benchmarks dataset in one place accompanied with detailed information about target systems from which this dataset was collected, then it will allow us to calculate precise baselines across different compositions of parameters, making performance deviations easier to detect. Long-term trend analysis can identify small changes and correlate them with updates, revealing performance drift. Another use of such a database - predictive modelling, which can provide forecasts of expected results and setting dynamic performance thresholds, enabling early issue detection. Anomaly detection becomes more effective with context, distinguishing unusual deviations from normal behaviour. # Interpretation of contradictory results It’s not clear how to deal with contradictory results to make a decision on regression presence. For example, we have a set of 10 tests, which test more or less the same, for example disk performance. It’s unclear what to do when one subset of tests show degradation and another subset shows neutral status or improvements. Is there a regression? I suppose that the availability of historical data can help to deal with such situations as historical data can show behaviour of particular tests and allow to assign weights in decision-making algorithms, but it’s just my guess. # System Profiles Tim's idea to reduce results to - “pass / fail” and my experience with various people trying to interpret benchmarking results led me to think of “profiles” - a set of parameters and metrics collected from a reference system while execution of a particular configuration of a particular benchmark. Profiles can be used for A/B comparison with pass/fail outcomes or match/not match, and this approach does not hide/miss the details and allows to capture multiple characteristics of the experiment, like presence of outliers/errors or skewed distribution form. Interested persons (like kernel developers or performance engineers, for example) can dig deeper to find a reason for such mismatch and those who are interested just in high-level results - pass/fail should be enough. Here is how I imaging a structure of a profile: --- profile_a: system packages: - pkg_1 - pkg_2 # Additional packages... settings: - cmdline # Additional settings... indicators: cpu: null ram: null loadavg: null # Additional indicators... benchmark: settings: param_1: null param_2: null param_x: null metrics: metric_1: null metric_2: null metric_x: null --- - System Packages, System Settings: Usually we do not pay much attention to this, but I think it’s worth highlighting that base OS is an important factor, as there are distribution-specific modifications present in the filesystem. Most commonly developers and researchers use Ubuntu (as the most popular distro) or Debian (as a cleaner and lightweight version of Ubuntu), but distributions apply their own patches to the kernel and system libraries, which may impact performance. Another kind of base OS - cloud OS images which can be modified by cloud providers to add internal packages & services which could potentially affect performance as well. While comparing we must take into account this aspect to compare apples-to-apples. - System Indicators: These are periodic statistics like CPU utilisation, RAM consumption, and other params collected before benchmarking, while benchmarking and after benchmarking. - Benchmark Settings: Benchmarking systems have multiple parameters, so it’s important to capture them and use them in analysis. - Benchmark Metrics: That’s obviously - benchmark results. It’s not a rare case when a benchmark test provides more than a single number. # Analysis Proposed rules-based analysis will work only for highly determined environments and systems, where rules can describe all the aspects. Rule-based systems are easier to understand and implement than other types, but for a small set of rules. However, we deal with the live system and it constantly evolves, so rules will deprecate extremely fast. It's the same story as with rule-based recommended systems in early years of machine learning. If you want to follow a rules-based approach, it's probably worth taking a look at https://www.clipsrules.net as this will allow to decouple results from analysis and avoid reinventing the analysis engine. Declaration of those rules will be error-prone due to the nature of their origin - they must be declared and maintained by humans. IMHO a human-less approach and use modern ML methods instead would be more beneficial in the long run. # Methodology Used methodology - another aspect which is not directly related to Tim's slides, but it's an important topic for results processing and interpretation, probably an idea of automated results interpretation can force use of one or another methodology. # Next steps I would be glad to participate in further discussions and share experience to improve kernel performance testing automation, analysis and interpretation of results. If there is interest, I'm open to collaborating on implementing some of these ideas. -- Best regards, Konstantin Belov

11 months, 1 week

2
1
0 0

[PATCH net-next v7 0/6] Suspend IRQs during application busy periods

by Joe Damato

Greetings: Welcome to v7, see changelog below. This revision drops patch 2 from the previous version, which was unnecessary as Jakub pointed out. The tests were fully re-run after dropping the patch to confirm the performance numbers hold; they do - see below. FAQ #2 has been updated to be more verbose, as well. This series introduces a new mechanism, IRQ suspension, which allows network applications using epoll to mask IRQs during periods of high traffic while also reducing tail latency (compared to existing mechanisms, see below) during periods of low traffic. In doing so, this balances CPU consumption with network processing efficiency. Martin Karsten (CC'd) and I have been collaborating on this series for several months and have appreciated the feedback from the community on our RFC [1]. We've updated the cover letter and kernel documentation in an attempt to more clearly explain how this mechanism works, how applications can use it, and how it compares to existing mechanisms in the kernel. I briefly mentioned this idea at netdev conf 2024 (for those who were there) and Martin described this idea in an earlier paper presented at Sigmetrics 2024 [2]. ~ The short explanation (TL;DR) We propose adding a new napi config parameter: irq_suspend_timeout to help balance CPU usage and network processing efficiency when using IRQ deferral and napi busy poll. If this parameter is set to a non-zero value *and* a user application has enabled preferred busy poll on a busy poll context (via the EPIOCSPARAMS ioctl introduced in commit 18e2bf0edf4d ("eventpoll: Add epoll ioctl for epoll_params")), then application calls to epoll_wait for that context will cause device IRQs and softirq processing to be suspended as long as epoll_wait successfully retrieves data from the NAPI. Each time data is retrieved, the irq_suspend_timeout is deferred. If/when network traffic subsides and epoll_wait returns no data, IRQ suspension is immediately reverted back to the existing napi_defer_hard_irqs and gro_flush_timeout mechanism which was introduced in commit 6f8b12d661d0 ("net: napi: add hard irqs deferral feature")). The irq_suspend_timeout serves as a safety mechanism. If userland takes a long time processing data, irq_suspend_timeout will fire and restart normal NAPI processing. For a more in depth explanation, please continue reading. ~ Comparison with existing mechanisms Interrupt mitigation can be accomplished in napi software, by setting napi_defer_hard_irqs and gro_flush_timeout, or via interrupt coalescing in the NIC. This can be quite efficient, but in both cases, a fixed timeout (or packet count) needs to be configured. However, a fixed timeout cannot effectively support both low- and high-load situations: At low load, an application typically processes a few requests and then waits to receive more input data. In this scenario, a large timeout will cause unnecessary latency. At high load, an application typically processes many requests before being ready to receive more input data. In this case, a small timeout will likely fire prematurely and trigger irq/softirq processing, which interferes with the application's execution. This causes overhead, most likely due to cache contention. While NICs attempt to provide adaptive interrupt coalescing schemes, these cannot properly take into account application-level processing. An alternative packet delivery mechanism is busy-polling, which results in perfect alignment of application processing and network polling. It delivers optimal performance (throughput and latency), but results in 100% cpu utilization and is thus inefficient for below-capacity workloads. We propose to add a new packet delivery mode that properly alternates between busy polling and interrupt-based delivery depending on busy and idle periods of the application. During a busy period, the system operates in busy-polling mode, which avoids interference. During an idle period, the system falls back to interrupt deferral, but with a small timeout to avoid excessive latencies. This delivery mode can also be viewed as an extension of basic interrupt deferral, but alternating between a small and a very large timeout. This delivery mode is efficient, because it avoids softirq execution interfering with application processing during busy periods. It can be used with blocking epoll_wait to conserve cpu cycles during idle periods. The effect of alternating between busy and idle periods is that performance (throughput and latency) is very close to full busy polling, while cpu utilization is lower and very close to interrupt mitigation. ~ Usage details IRQ suspension is introduced via a per-NAPI configuration parameter that controls the maximum time that IRQs can be suspended. Here's how it is intended to work: - The user application (or system administrator) uses the netdev-genl netlink interface to set the pre-existing napi_defer_hard_irqs and gro_flush_timeout NAPI config parameters to enable IRQ deferral. - The user application (or system administrator) sets the proposed irq_suspend_timeout parameter via the netdev-genl netlink interface to a larger value than gro_flush_timeout to enable IRQ suspension. - The user application issues the existing epoll ioctl to set the prefer_busy_poll flag on the epoll context. - The user application then calls epoll_wait to busy poll for network events, as it normally would. - If epoll_wait returns events to userland, IRQs are suspended for the duration of irq_suspend_timeout. - If epoll_wait finds no events and the thread is about to go to sleep, IRQ handling using napi_defer_hard_irqs and gro_flush_timeout is resumed. As long as epoll_wait is retrieving events, IRQs (and softirq processing) for the NAPI being polled remain disabled. When network traffic reduces, eventually a busy poll loop in the kernel will retrieve no data. When this occurs, regular IRQ deferral using gro_flush_timeout for the polled NAPI is re-enabled. Unless IRQ suspension is continued by subsequent calls to epoll_wait, it automatically times out after the irq_suspend_timeout timer expires. Regular deferral is also immediately re-enabled when the epoll context is destroyed. ~ Usage scenario The target scenario for IRQ suspension as packet delivery mode is a system that runs a dominant application with substantial network I/O. The target application can be configured to receive input data up to a certain batch size (via epoll_wait maxevents parameter) and this batch size determines the worst-case latency that application requests might experience. Because packet delivery is suspended during the target application's processing, the batch size also determines the worst-case latency of concurrent applications using the same RX queue(s). gro_flush_timeout should be set as small as possible, but large enough to make sure that a single request is likely not being interfered with. irq_suspend_timeout is largely a safety mechanism against misbehaving applications. It should be set large enough to cover the processing of an entire application batch, i.e., the factor between gro_flush_timeout and irq_suspend_timeout should roughly correspond to the maximum batch size that the target application would process in one go. ~ Important call out in the implementation - Enabling per epoll-context preferred busy poll will now effectively lead to a nonblocking iteration through napi_busy_loop, even when busy_poll_usecs is 0. See patch 4. ~ Benchmark configs & descriptions The changes were benchmarked with memcached [3] using the benchmarking tool mutilate [4]. To facilitate benchmarking, a small patch [5] was applied to memcached 1.6.29 to allow setting per-epoll context preferred busy poll and other settings via environment variables. Another small patch [6] was applied to libevent to enable full busy-polling. Multiple scenarios were benchmarked as described below and the scripts used for producing these results can be found on github [7] (note: all scenarios use NAPI-based traffic splitting via SO_INCOMING_ID by passing -N to memcached): - base: - no other options enabled - deferX: - set defer_hard_irqs to 100 - set gro_flush_timeout to X,000 - napibusy: - set defer_hard_irqs to 100 - set gro_flush_timeout to 200,000 - enable busy poll via the existing ioctl (busy_poll_usecs = 64, busy_poll_budget = 64, prefer_busy_poll = true) - fullbusy: - set defer_hard_irqs to 100 - set gro_flush_timeout to 5,000,000 - enable busy poll via the existing ioctl (busy_poll_usecs = 1000, busy_poll_budget = 64, prefer_busy_poll = true) - change memcached's nonblocking epoll_wait invocation (via libevent) to using a 1 ms timeout - suspend0: - set defer_hard_irqs to 0 - set gro_flush_timeout to 0 - set irq_suspend_timeout to 20,000,000 - enable busy poll via the existing ioctl (busy_poll_usecs = 0, busy_poll_budget = 64, prefer_busy_poll = true) - suspendX: - set defer_hard_irqs to 100 - set gro_flush_timeout to X,000 - set irq_suspend_timeout to 20,000,000 - enable busy poll via the existing ioctl (busy_poll_usecs = 0, busy_poll_budget = 64, prefer_busy_poll = true) ~ Benchmark results Tested on: Single socket AMD EPYC 7662 64-Core Processor Hyperthreading disabled 4 NUMA Zones (NPS=4) 16 CPUs per NUMA zone (64 cores total) 2 x Dual port 100gbps Mellanox Technologies ConnectX-5 Ex EN NIC The test machine is configured such that a single interface has 8 RX queues. The queues' IRQs and memcached are pinned to CPUs that are NUMA-local to the interface which is under test. The NIC's interrupt coalescing configuration is left at boot-time defaults. Results: Results are shown below. The mechanism added by this series is represented by the 'suspend' cases. Data presented shows a summary over nearly 10 runs of each test case [8] using the scripts on github [7]. For latency, the median is shown. For throughput and CPU utilization, the average is shown. The results also include cycles-per-query (cpq) and instruction-per-query (ipq) metrics, following the methodology proposed in [2], to augment the CPU utilization numbers, which could be skewed due to frequency scaling. We find that this does not appear to be the case as CPU utilization and low-level metrics show similar trends. These results were captured using the scripts on github [7] to illustrate how this approach compares with other pre-existing mechanisms. This data is not to be interpreted as scientific data captured in a fully isolated lab setting, but instead as best effort, illustrative information comparing and contrasting tradeoffs. The absolute QPS results shift between submissions, but the relative differences are equivalent. As patches are rebased, several factors likely influence overall performance. Compare: - Throughput (MAX) and latencies of base vs suspend. - CPU usage of napibusy and fullbusy during lower load (200K, 400K for example) vs suspend. - Latency of the defer variants vs suspend as timeout and load increases. - suspend0, which sets defer_hard_irqs and gro_flush_timeout to 0, has nearly the same performance as the base case (this is FAQ item #1). The overall takeaway is that the suspend variants provide a superior combination of high throughput, low latency, and low cpu utilization compared to all other variants. Each of the suspend variants works very well, but some fine-tuning between latency and cpu utilization is still possible by tuning the small timeout (gro_flush_timeout). Note: we've reorganized the results to make comparison among testcases with the same load easier. testcase load qps avglat 95%lat 99%lat cpu cpq ipq base 200K 199946 112 239 416 26 12973 11343 defer10 200K 199971 54 124 142 29 19412 17460 defer20 200K 199986 60 130 153 26 15644 14095 defer50 200K 200025 79 144 182 23 12122 11632 defer200 200K 199999 164 254 309 19 8923 9635 fullbusy 200K 199998 46 118 133 100 43658 23133 napibusy 200K 199983 100 237 277 56 24840 24716 suspend0 200K 200020 105 249 432 30 14264 11796 suspend10 200K 199950 53 123 141 32 19518 16903 suspend20 200K 200037 58 126 151 30 16426 14736 suspend50 200K 199961 73 136 177 26 13310 12633 suspend200 200K 199998 149 251 306 21 9566 10203 testcase load qps avglat 95%lat 99%lat cpu cpq ipq base 400K 400014 139 269 707 41 9476 9343 defer10 400K 400016 59 133 166 53 13991 12989 defer20 400K 399952 67 140 172 47 12063 11644 defer50 400K 400007 87 162 198 39 9384 9880 defer200 400K 399979 181 274 330 31 7089 8430 fullbusy 400K 399987 50 123 156 100 21827 16037 napibusy 400K 400014 76 222 272 83 18185 16529 suspend0 400K 400015 127 350 776 47 10699 9603 suspend10 400K 400023 57 129 164 54 13758 13178 suspend20 400K 400043 62 135 169 49 12071 11826 suspend50 400K 400071 76 149 186 42 10011 10301 suspend200 400K 399961 154 269 327 34 7827 8774 testcase load qps avglat 95%lat 99%lat cpu cpq ipq base 600K 599951 149 266 574 61 9265 8876 defer10 600K 600006 71 147 203 76 11866 10936 defer20 600K 600123 76 152 203 66 10430 10342 defer50 600K 600162 95 172 217 54 8526 9142 defer200 600K 599942 200 301 357 46 6977 8212 fullbusy 600K 599990 55 127 177 100 14551 13983 napibusy 600K 600035 63 160 250 96 13937 14140 suspend0 600K 599903 127 320 732 68 10166 8963 suspend10 600K 599908 63 137 192 69 10902 11100 suspend20 600K 599961 66 141 194 65 9976 10370 suspend50 600K 599973 80 159 204 57 8678 9381 suspend200 600K 600010 157 277 346 48 7133 8381 testcase load qps avglat 95%lat 99%lat cpu cpq ipq base 800K 800039 181 300 536 87 9585 8304 defer10 800K 800038 181 530 939 96 10564 8970 defer20 800K 800029 112 225 329 90 10056 8935 defer50 800K 799999 120 208 296 82 9234 8562 defer200 800K 800066 227 338 401 63 7117 8129 fullbusy 800K 800040 61 134 190 100 10913 12608 napibusy 800K 799944 64 141 214 99 10828 12588 suspend0 800K 799911 126 248 509 85 9346 8498 suspend10 800K 800006 69 143 200 83 9410 9845 suspend20 800K 800120 74 150 207 78 8786 9454 suspend50 800K 799989 87 168 224 71 7946 8833 suspend200 800K 799987 160 292 357 62 6923 8229 testcase load qps avglat 95%lat 99%lat cpu cpq ipq base 1000K 906879 4079 5751 6216 98 9496 7904 defer10 1000K 860849 3643 6274 6730 99 10040 8676 defer20 1000K 896063 3298 5840 6349 98 9620 8237 defer50 1000K 919782 2962 5513 5807 97 9284 7951 defer200 1000K 970941 3059 5348 5984 95 8593 7959 fullbusy 1000K 999950 70 150 207 100 8732 10777 napibusy 1000K 999996 78 154 223 100 8722 10656 suspend0 1000K 949706 2666 5770 6660 99 9071 8046 suspend10 1000K 1000024 80 160 220 92 8137 9035 suspend20 1000K 1000059 83 165 226 89 7850 8804 suspend50 1000K 999955 95 180 240 84 7411 8459 suspend200 1000K 999914 163 299 366 77 6833 8078 testcase load qps avglat 95%lat 99%lat cpu cpq ipq base MAX 1037654 4184 5453 5810 100 8411 7938 defer10 MAX 905607 4840 6151 6380 100 9639 8431 defer20 MAX 986463 4455 5594 5796 100 8848 8110 defer50 MAX 1077030 4000 5073 5299 100 8104 7920 defer200 MAX 1040728 4152 5385 5765 100 8379 7849 fullbusy MAX 1247536 3518 3935 3984 100 6998 7930 napibusy MAX 1136310 3799 7756 9964 100 7670 7877 suspend0 MAX 1057509 4132 5724 6185 100 8253 7918 suspend10 MAX 1215147 3580 3957 4041 100 7185 7944 suspend20 MAX 1216469 3576 3953 3988 100 7175 7950 suspend50 MAX 1215871 3577 3961 4075 100 7181 7949 suspend200 MAX 1216882 3556 3951 3988 100 7175 7955 ~ FAQ - Why is a new parameter needed? Does irq_suspend_timeout override gro_flush_timeout? Using the suspend mechanism causes the system to alternate between polling mode and irq-driven packet delivery. During busy periods, irq_suspend_timeout overrides gro_flush_timeout and keeps the system busy polling, but when epoll finds no events, the setting of gro_flush_timeout and napi_defer_hard_irqs determine the next step. There are essentially three possible loops for network processing and packet delivery: 1) hardirq -> softirq -> napi poll; basic interrupt delivery 2) timer -> softirq -> napi poll; deferred irq processing 3) epoll -> busy-poll -> napi poll; busy looping Loop 2 can take control from Loop 1, if gro_flush_timeout and napi_defer_hard_irqs are set. If gro_flush_timeout and napi_defer_hard_irqs are set, Loops 2 and 3 "wrestle" with each other for control. During busy periods, irq_suspend_timeout is used as timer in Loop 2, which essentially tilts this in favour of Loop 3. If gro_flush_timeout and napi_defer_hard_irqs are not set, Loop 3 cannot take control from Loop 1. Therefore, setting gro_flush_timeout and napi_defer_hard_irqs is the recommended usage, because otherwise setting irq_suspend_timeout might not have any discernible effect. This is shown in the results above: compare suspend0 with the base case. Note that the lack of napi_defer_hard_irqs and gro_flush_timeout produce similar results for both, which encourages the use of napi_defer_hard_irqs and gro_flush_timeout in addition to irq_suspend_timeout. - Can the new timeout value be threaded through the new epoll ioctl ? It is possible, but presents challenges for userspace. User applications must ensure that the file descriptors added to epoll contexts have the same NAPI ID to support busy polling. An epoll context is not permanently tied to any particular NAPI ID. So, a user application could decide to clear the file descriptors from the context and add a new set of file descriptors with a different NAPI ID to the context. Busy polling would work as expected, but the meaning of the suspend timeout becomes ambiguous because IRQs are not inherently associated with epoll contexts, but rather with the NAPI. The user program would need to reissue the ioctl to set the irq_suspend_timeout, but the napi_defer_hard_irqs and gro_flush_timeout settings would come from the NAPI's napi_config (which are set either by sysfs or by netlink). Such an interface seems awkard to use from a user perspective. Further, IRQs are related to NAPIs, which is why they are stored in the napi_config space. Putting the irq_suspend_timeout in the epoll context while other IRQ deferral mechanisms remain in the NAPI's napi_config space seems like an odd design choice. We've opted to keep all of the IRQ deferral parameters together and place the irq_suspend_timeout in napi_config. This has nice benefits for userspace: if a user app were to remove all file descriptors from an epoll context and add new file descriptors with a new NAPI ID, the correct suspend timeout for that NAPI ID would be used automatically without the user application needing to do anything (like re-issuing an ioctl, for example). All IRQ deferral related parameters are in one place and can all be set the same way: with netlink. - Can irq suspend be built by combining NIC coalescing and gro_flush_timeout ? No. The problem is that the long timeout must engage if and only if prefer-busy is active. When using NIC coalescing for the short timeout (without napi_defer_hard_irqs/gro_flush_timeout), an interrupt after an idle period will trigger softirq, which will run napi polling. At this point, prefer-busy is not active, so NIC interrupts would be re-enabled. Then it is not possible for the longer timeout to interject to switch control back to polling. In other words, only by using the software timer for the short timeout, it is possible to extend the timeout without having to reprogram the NIC timer or reach down directly and disable interrupts. Using gro_flush_timeout for the long timeout also has problems, for the same underlying reason. In the current napi implementation, gro_flush_timeout is not tied to prefer-busy. We'd either have to change that and in the process modify the existing deferral mechanism, or introduce a state variable to determine whether gro_flush_timeout is used as long timeout for irq suspend or whether it is used for its default purpose. In an earlier version, we did try something similar to the latter and made it work, but it ends up being a lot more convoluted than our current proposal. - Isn't it already possible to combine busy looping with irq deferral? Yes, in fact enabling irq deferral via napi_defer_hard_irqs and gro_flush_timeout is a precondition for prefer_busy_poll to have an effect. If the application also uses a tight busy loop with essentially nonblocking epoll_wait (accomplished with a very short timeout parameter), this is the fullbusy case shown in the results. An application using blocking epoll_wait is shown as the napibusy case in the results. It's a hybrid approach that provides limited latency benefits compared to the base case and plain irq deferral, but not as good as fullbusy or suspend. ~ Special thanks Several people were involved in earlier stages of the development of this mechanism whom we'd like to thank: - Peter Cai (CC'd), for the initial kernel patch and his contributions to the paper. - Mohammadamin Shafie (CC'd), for testing various versions of the kernel patch and providing helpful feedback. Thanks, Martin and Joe [1]: https://lore.kernel.org/netdev/20240812125717.413108-1-jdamato@fastly.com/ [2]: https://doi.org/10.1145/3626780 [3]: https://github.com/memcached/memcached/blob/master/doc/napi_ids.txt [4]: https://github.com/leverich/mutilate [5]: https://raw.githubusercontent.com/martinkarsten/irqsuspend/main/patches/mem… [6]: https://raw.githubusercontent.com/martinkarsten/irqsuspend/main/patches/lib… [7]: https://github.com/martinkarsten/irqsuspend [8]: https://github.com/martinkarsten/irqsuspend/tree/main/results v7: - Jakub noted that patch 2 adds unnecessary complexity by checking the suspend timeout in the NAPI loop. This makes the code more complicated and difficult to reason about. He's right; we've dropped patch 2 which simplifies this series. - Updated the cover letter with a full re-run of all test cases. - Updated FAQ #2. v6: https://lore.kernel.org/netdev/20241104215542.215919-1-jdamato@fastly.com/ - Updated the cover letter with a full re-run of all test cases, including a new case suspend0, as requested by Sridhar previously. - Updated the kernel documentation in patch 7 as suggested by Bagas Sanjaya, which improved the htmldoc output. v5: https://lore.kernel.org/netdev/20241103052421.518856-1-jdamato@fastly.com/ - Adjusted patch 5 to only suspend IRQs when ep_send_events returns a positive return value. This issue was pointed out by Hillf Danton. - Updated the commit message of patch 6 which still mentioned netcat, despite the code being updated in v4 to replace it with socat and fixed misspelling of netdevsim. - Fixed a minor typo in patch 7 and removed an unnecessary paragraph. - Added Sridhar Samudrala's Reviewed-by to patch 1-5 and 7. v4: https://lore.kernel.org/netdev/20241102005214.32443-1-jdamato@fastly.com/ - Added a new FAQ item to cover letter. - Updated patch 6 to use socat instead of nc in busy_poll_test.sh and updated busy_poller.c to use netlink directly to configure napi params. - Updated the kernel documentation in patch 7 to include more details. - Dropped Stanislav's Acked-by and Bagas' Reviewed-by from patch 7 since the documentation was updated. v3: https://lore.kernel.org/netdev/20241101004846.32532-1-jdamato@fastly.com/ - Added Stanislav Fomichev's Acked-by to every patch except the newly added selftest. - Added Bagas Sanjaya's Reviewed-by to the documentation patch. - Fixed the commit message of patch 2 to remove a reference to the now non-existent sysfs setting. - Added a self test which tests both "regular" busy poll and busy poll with suspend enabled. This was added as patch 6 as requested by Paolo. netdevsim was chosen instead of veth due to netdevsim's pre-existing support for netdev-genl. See the commit message of patch 6 for more details. v2: https://lore.kernel.org/bpf/20241021015311.95468-1-jdamato@fastly.com/ - Cover letter updated, including a re-run of test data. - Patch 1 rewritten to use netdev-genl instead of sysfs. - Patch 3 updated with a comment added to napi_resume_irqs. - Patch 4 rebased to apply now that commit b9ca079dd6b0 ("eventpoll: Annotate data-race of busy_poll_usecs") has been picked up from VFS. - Patch 6 updated the kernel documentation. rfc -> v1: - Cover letter updated to include more details. - Patch 1 updated to remove the documentation added. This was moved to patch 6 with the rest of the docs (see below). - Patch 5 updated to fix an error uncovered by the kernel build robot. See patch 5's changelog for more details. - Patch 6 added which updates kernel documentation. Joe Damato (2): selftests: net: Add busy_poll_test docs: networking: Describe irq suspension Martin Karsten (4): net: Add napi_struct parameter irq_suspend_timeout net: Add control functions for irq suspension eventpoll: Trigger napi_busy_loop, if prefer_busy_poll is set eventpoll: Control irq suspension for prefer_busy_poll Documentation/netlink/specs/netdev.yaml | 7 + Documentation/networking/napi.rst | 170 ++++++++- fs/eventpoll.c | 36 +- include/linux/netdevice.h | 2 + include/net/busy_poll.h | 3 + include/uapi/linux/netdev.h | 1 + net/core/dev.c | 41 +++ net/core/dev.h | 25 ++ net/core/netdev-genl-gen.c | 5 +- net/core/netdev-genl.c | 12 + tools/include/uapi/linux/netdev.h | 1 + tools/testing/selftests/net/.gitignore | 1 + tools/testing/selftests/net/Makefile | 3 +- tools/testing/selftests/net/busy_poll_test.sh | 164 +++++++++ tools/testing/selftests/net/busy_poller.c | 328 ++++++++++++++++++ 15 files changed, 792 insertions(+), 7 deletions(-) create mode 100755 tools/testing/selftests/net/busy_poll_test.sh create mode 100644 tools/testing/selftests/net/busy_poller.c base-commit: dc7c381bb8649e3701ed64f6c3e55316675904d7 -- 2.25.1

11 months, 1 week

1
1
0 0

[PATCH net-next v1 0/7] devmem TCP fixes

by Mina Almasry

A few unrelated devmem TCP fixes bundled in a series for some convenience (if that's ok). Patch 1-2: fix naming and provide page_pool_alloc_netmem for fragged netmem. Patch 3-4: fix issues with dma-buf dma addresses being potentially passed to dma_sync_for_* helpers. Patch 5-6: fix syzbot SO_DEVMEM_DONTNEED issue and add test for this case. Mina Almasry (6): net: page_pool: rename page_pool_alloc_netmem to *_netmems net: page_pool: create page_pool_alloc_netmem page_pool: disable sync for cpu for dmabuf memory provider netmem: add netmem_prefetch net: fix SO_DEVMEM_DONTNEED looping too long ncdevmem: add test for too many token_count Samiullah Khawaja (1): page_pool: Set `dma_sync` to false for devmem memory provider include/net/netmem.h | 7 ++++ include/net/page_pool/helpers.h | 50 ++++++++++++++++++-------- include/net/page_pool/types.h | 2 +- net/core/devmem.c | 9 +++-- net/core/page_pool.c | 11 +++--- net/core/sock.c | 46 ++++++++++++++---------- tools/testing/selftests/net/ncdevmem.c | 11 ++++++ 7 files changed, 93 insertions(+), 43 deletions(-) -- 2.47.0.163.g1226f6d8fa-goog

11 months, 1 week

3
9
0 0

[PATCH v6 00/10] iommufd: Add vIOMMU infrastructure (Part-2: vDEVICE)

by Nicolin Chen

Following the previous vIOMMU series, this adds another vDEVICE structure, representing the association from an iommufd_device to an iommufd_viommu. This gives the whole architecture a new "v" layer: _______________________________________________________________________ | iommufd (with vIOMMU/vDEVICE) | | _____________ _____________ | | | | | | | | |----------------| vIOMMU |<---| vDEVICE |<------| | | | | | |_____________| | | | | ______ | | _____________ ___|____ | | | | | | | | | | | | | | | IOAS |<---|(HWPT_PAGING)|<---| HWPT_NESTED |<--| DEVICE | | | | |______| |_____________| |_____________| |________| | |______|________|______________|__________________|_______________|_____| | | | | | ______v_____ | ______v_____ ______v_____ ___v__ | struct | | PFN | (paging) | | (nested) | |struct| |iommu_device| |------>|iommu_domain|<----|iommu_domain|<----|device| |____________| storage|____________| |____________| |______| This vDEVICE object is used to collect and store all vIOMMU-related device information/attributes in a VM. As an initial series for vDEVICE, add only the virt_id to the vDEVICE, which is a vIOMMU specific device ID in a VM: e.g. vSID of ARM SMMUv3, vDeviceID of AMD IOMMU, and vRID of Intel VT-d to a Context Table. This virt_id helps IOMMU drivers to link the vID to a pID of the device against the physical IOMMU instance. This is essential for a vIOMMU-based invalidation, where the request contains a device's vID for a device cache flush, e.g. ATC invalidation. Therefore, with this vDEVICE object, support a vIOMMU-based invalidation, by reusing IOMMUFD_CMD_HWPT_INVALIDATE for a vIOMMU object to flush cache with a given driver data. As for the implementation of the series, add driver support in ARM SMMUv3 for a real world use case. This series is on Github: https://github.com/nicolinc/iommufd/commits/iommufd_viommu_p2-v6 (QEMU branch for testing will be provided in Jason's nesting series) Changelog v6 * Fixed kdoc in the uAPI header * Fixed indentations in iommufd.rst * Replaced vdev->idev with vdev->dev * Added "Reviewed-by" from Kevin and Jason * Updated kdoc of struct iommu_vdevice_alloc * Fixed lockdep function call in iommufd_viommu_find_dev * Added missing iommu_dev validation between viommu and idev * Skipped SMMUv3 driver changes (to post in a separate series) * Replaced !cache_invalidate_user in WARN_ON of the allocation path with cache_invalidate_user validation in iommufd_hwpt_invalidate v5 https://lore.kernel.org/all/cover.1729897278.git.nicolinc@nvidia.com/ * Dropped driver-allocated vDEVICE support * Changed vdev_to_dev helper to iommufd_viommu_find_dev v4 https://lore.kernel.org/all/cover.1729555967.git.nicolinc@nvidia.com/ * Added missing brackets in switch-case * Fixed the unreleased idev refcount issue * Reworked the iommufd_vdevice_alloc allocator * Dropped support for IOMMU_VIOMMU_TYPE_DEFAULT * Added missing TEST_LENGTH and fail_nth coverages * Added a verification to the driver-allocated vDEVICE object * Added an iommufd_vdevice_abort for a missing mutex protection * Added a u64 structure arm_vsmmu_invalidation_cmd for user command conversion v3 https://lore.kernel.org/all/cover.1728491532.git.nicolinc@nvidia.com/ * Added Jason's Reviewed-by * Split this invalidation part out of the part-1 series * Repurposed VDEV_ID ioctl to a wider vDEVICE structure and ioctl * Reduced viommu_api functions by allowing drivers to access viommu and vdevice structure directly * Dropped vdevs_rwsem by using xa_lock instead * Dropped arm_smmu_cache_invalidate_user v2 https://lore.kernel.org/all/cover.1724776335.git.nicolinc@nvidia.com/ * Limited vdev_id to one per idev * Added a rw_sem to protect the vdev_id list * Reworked driver-level APIs with proper lockings * Added a new viommu_api file for IOMMUFD_DRIVER config * Dropped useless iommu_dev point from the viommu structure * Added missing index numnbers to new types in the uAPI header * Dropped IOMMU_VIOMMU_INVALIDATE uAPI; Instead, reuse the HWPT one * Reworked mock_viommu_cache_invalidate() using the new iommu helper * Reordered details of set/unset_vdev_id handlers for proper lockings v1 https://lore.kernel.org/all/cover.1723061377.git.nicolinc@nvidia.com/ Thanks! Nicolin Jason Gunthorpe (1): iommu: Add iommu_copy_struct_from_full_user_array helper Nicolin Chen (9): iommufd/viommu: Add IOMMUFD_OBJ_VDEVICE and IOMMU_VDEVICE_ALLOC ioctl iommufd/selftest: Add IOMMU_VDEVICE_ALLOC test coverage iommu/viommu: Add cache_invalidate to iommufd_viommu_ops iommufd: Allow hwpt_id to carry viommu_id for IOMMU_HWPT_INVALIDATE iommufd/viommu: Add iommufd_viommu_find_dev helper iommufd/selftest: Add mock_viommu_cache_invalidate iommufd/selftest: Add IOMMU_TEST_OP_DEV_CHECK_CACHE test command iommufd/selftest: Add vIOMMU coverage for IOMMU_HWPT_INVALIDATE ioctl Documentation: userspace-api: iommufd: Update vDEVICE drivers/iommu/iommufd/iommufd_private.h | 18 ++ drivers/iommu/iommufd/iommufd_test.h | 30 +++ include/linux/iommu.h | 48 ++++- include/linux/iommufd.h | 22 ++ include/uapi/linux/iommufd.h | 31 ++- tools/testing/selftests/iommu/iommufd_utils.h | 83 +++++++ drivers/iommu/iommufd/driver.c | 13 ++ drivers/iommu/iommufd/hw_pagetable.c | 40 +++- drivers/iommu/iommufd/main.c | 6 + drivers/iommu/iommufd/selftest.c | 98 ++++++++- drivers/iommu/iommufd/viommu.c | 76 +++++++ tools/testing/selftests/iommu/iommufd.c | 204 +++++++++++++++++- .../selftests/iommu/iommufd_fail_nth.c | 4 + Documentation/userspace-api/iommufd.rst | 41 +++- 14 files changed, 688 insertions(+), 26 deletions(-) -- 2.43.0

11 months, 1 week

4
25
0 0

[PATCH v6 00/13] iommufd: Add vIOMMU infrastructure (Part-1)

by Nicolin Chen

This series introduces a new vIOMMU infrastructure and related ioctls. IOMMUFD has been using the HWPT infrastructure for all cases, including a nested IO page table support. Yet, there're limitations for an HWPT-based structure to support some advanced HW-accelerated features, such as CMDQV on NVIDIA Grace, and HW-accelerated vIOMMU on AMD. Even for a multi-IOMMU environment, it is not straightforward for nested HWPTs to share the same parent HWPT (stage-2 IO pagetable), with the HWPT infrastructure alone: a parent HWPT typically hold one stage-2 IO pagetable and tag it with only one ID in the cache entries. When sharing one large stage-2 IO pagetable across physical IOMMU instances, that one ID may not always be available across all the IOMMU instances. In other word, it's ideal for SW to have a different container for the stage-2 IO pagetable so it can hold another ID that's available. And this container will be able to hold some advanced feature too. For this "different container", add vIOMMU, an additional layer to hold extra virtualization information: _______________________________________________________________________ | iommufd (with vIOMMU) | | _____________ | | | | | | |----------------| vIOMMU | | | | ______ | | _____________ ________ | | | | | | | | | | | | | | | IOAS |<---|(HWPT_PAGING)|<---| HWPT_NESTED |<--| DEVICE | | | | |______| |_____________| |_____________| |________| | | | | | | | | |______|________|______________|__________________|_______________|_____| | | | | | ______v_____ | ______v_____ ______v_____ ___v__ | struct | | PFN | (paging) | | (nested) | |struct| |iommu_device| |------>|iommu_domain|<----|iommu_domain|<----|device| |____________| storage|____________| |____________| |______| The vIOMMU object should be seen as a slice of a physical IOMMU instance that is passed to or shared with a VM. That can be some HW/SW resources: - Security namespace for guest owned ID, e.g. guest-controlled cache tags - Non-device-affiliated event reporting, e.g. invalidation queue errors - Access to a sharable nesting parent pagetable across physical IOMMUs - Virtualization of various platforms IDs, e.g. RIDs and others - Delivery of paravirtualized invalidation - Direct assigned invalidation queues - Direct assigned interrupts On a multi-IOMMU system, the vIOMMU object must be instanced to the number of the physical IOMMUs that have a slice passed to (via device) a guest VM, while being able to hold the shareable parent HWPT. Each vIOMMU then just needs to allocate its own individual ID to tag its own cache: ---------------------------- ---------------- | | paging_hwpt0 | | hwpt_nested0 |--->| viommu0 ------------------ ---------------- | | IDx | ---------------------------- ---------------------------- ---------------- | | paging_hwpt0 | | hwpt_nested1 |--->| viommu1 ------------------ ---------------- | | IDy | ---------------------------- As an initial part-1, add IOMMUFD_CMD_VIOMMU_ALLOC ioctl for an allocation only. More vIOMMU-based structs and ioctls will be introduced in the follow-up series to support vDEVICE, vIRQ (vEVENT) and vQUEUE objects. Although we repurposed the vIOMMU object from an earlier RFC, just for a referece: https://lore.kernel.org/all/cover.1712978212.git.nicolinc@nvidia.com/ This series is on Github: https://github.com/nicolinc/iommufd/commits/iommufd_viommu_p1-v6 (QEMU branch for testing will be provided in Jason's nesting series) Changelog v6 * Improved comment lines * Added a TEST_F for IO page fault * Fixed indentations in iommufd.rst * Revised kdoc of the viommu_alloc op * Added "Reviewed-by" from Kevin and Jason * Passed in "flags" to ->alloc_domain_nested * Renamed "free" op to "destroy" in viommu_ops * Skipped SMMUv3 driver changes (to post in a separate series) * Fixed "flags" validation in iommufd_viommu_alloc_hwpt_nested * Added CONFIG_IOMMUFD_DRIVER_CORE for sharing between iommufd core and IOMMU dirvers * Replaced iommufd_verify_unfinalized_object with xa_cmpxchg in iommufd_object_finalize/abort functions v5 https://lore.kernel.org/all/cover.1729897352.git.nicolinc@nvidia.com/ * Added "Reviewed-by" from Kevin * Reworked iommufd_viommu_alloc helper * Revised the uAPI kdoc for vIOMMU object * Revised comments for pluggable iommu_dev * Added a couple of cleanup patches for selftest * Renamed domain_alloc_nested op to alloc_domain_nested * Updated a few commit messages to reflect the latest series * Renamed iommufd_hwpt_nested_alloc_for_viommu to iommufd_viommu_alloc_hwpt_nested, and added flag validation v4 https://lore.kernel.org/all/cover.1729553811.git.nicolinc@nvidia.com/ * Added "Reviewed-by" from Jason * Dropped IOMMU_VIOMMU_TYPE_DEFAULT support * Dropped iommufd_object_alloc_elm renamings * Renamed iommufd's viommu_api.c to driver.c * Reworked iommufd_viommu_alloc helper * Added a separate iommufd_hwpt_nested_alloc_for_viommu function for hwpt_nested allocations on a vIOMMU, and added comparison between viommu->iommu_dev->ops and dev_iommu_ops(idev->dev) * Replaced s2_parent with vsmmu in arm_smmu_nested_domain * Replaced domain_alloc_user in iommu_ops with domain_alloc_nested in viommu_ops * Replaced wait_queue_head_t with a completion, to delay the unplug of mock_iommu_dev * Corrected documentation graph that was missing struct iommu_device * Added an iommufd_verify_unfinalized_object helper to verify driver- allocated vIOMMU/vDEVICE objects * Added missing test cases for TEST_LENGTH and fail_nth v3 https://lore.kernel.org/all/cover.1728491453.git.nicolinc@nvidia.com/ * Rebased on top of Jason's nesting v3 series https://lore.kernel.org/all/0-v3-e2e16cd7467f+2a6a1-smmuv3_nesting_jgg@nvid… * Split the series into smaller parts * Added Jason's Reviewed-by * Added back viommu->iommu_dev * Added support for driver-allocated vIOMMU v.s. core-allocated * Dropped arm_smmu_cache_invalidate_user * Added an iommufd_test_wait_for_users() in selftest * Reworked test code to make viommu an individual FIXTURE * Added missing TEST_LENGTH case for the new ioctl command v2 https://lore.kernel.org/all/cover.1724776335.git.nicolinc@nvidia.com/ * Limited vdev_id to one per idev * Added a rw_sem to protect the vdev_id list * Reworked driver-level APIs with proper lockings * Added a new viommu_api file for IOMMUFD_DRIVER config * Dropped useless iommu_dev point from the viommu structure * Added missing index numnbers to new types in the uAPI header * Dropped IOMMU_VIOMMU_INVALIDATE uAPI; Instead, reuse the HWPT one * Reworked mock_viommu_cache_invalidate() using the new iommu helper * Reordered details of set/unset_vdev_id handlers for proper lockings v1 https://lore.kernel.org/all/cover.1723061377.git.nicolinc@nvidia.com/ Thanks! Nicolin Nicolin Chen (13): iommufd: Move struct iommufd_object to public iommufd header iommufd: Move _iommufd_object_alloc helper to a sharable file iommufd: Introduce IOMMUFD_OBJ_VIOMMU and its related struct iommufd: Verify object in iommufd_object_finalize/abort() iommufd/viommu: Add IOMMU_VIOMMU_ALLOC ioctl iommufd: Add alloc_domain_nested op to iommufd_viommu_ops iommufd: Allow pt_id to carry viommu_id for IOMMU_HWPT_ALLOC iommufd/selftest: Add container_of helpers iommufd/selftest: Prepare for mock_viommu_alloc_domain_nested() iommufd/selftest: Add refcount to mock_iommu_device iommufd/selftest: Add IOMMU_VIOMMU_TYPE_SELFTEST iommufd/selftest: Add IOMMU_VIOMMU_ALLOC test coverage Documentation: userspace-api: iommufd: Update vIOMMU drivers/iommu/iommufd/Kconfig | 5 + drivers/iommu/iommufd/Makefile | 8 +- drivers/iommu/iommufd/iommufd_private.h | 33 +-- drivers/iommu/iommufd/iommufd_test.h | 2 + include/linux/iommu.h | 14 + include/linux/iommufd.h | 83 ++++++ include/uapi/linux/iommufd.h | 54 +++- tools/testing/selftests/iommu/iommufd_utils.h | 28 ++ drivers/iommu/iommufd/driver.c | 40 +++ drivers/iommu/iommufd/hw_pagetable.c | 72 ++++- drivers/iommu/iommufd/main.c | 54 ++-- drivers/iommu/iommufd/selftest.c | 266 +++++++++++++----- drivers/iommu/iommufd/viommu.c | 81 ++++++ tools/testing/selftests/iommu/iommufd.c | 128 +++++++++ .../selftests/iommu/iommufd_fail_nth.c | 11 + Documentation/userspace-api/iommufd.rst | 69 ++++- 16 files changed, 795 insertions(+), 153 deletions(-) create mode 100644 drivers/iommu/iommufd/driver.c create mode 100644 drivers/iommu/iommufd/viommu.c -- 2.43.0

11 months, 1 week

3
23
0 0

[PATCH v2 0/2] kselftest/arm64: fp-stress signal delivery interval improvements

by Mark Brown

One of the things that fp-stress does to stress the floating point context switching is send signals to the test threads it spawns. Currently we do this once per second but as suggested by Mark Rutland if we increase this we can improve the chances of triggering any issues with context switching the signal handling code. Do a quick change to increase the rate of signal delivery, trying to avoid excessive impact on emulated platforms, and a further change to mitigate the impact that this creates during startup. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- Changes in v2: - Minor clarifications in commit message and log output. - Link to v1: https://lore.kernel.org/r/20241029-arm64-fp-stress-interval-v1-0-db540abf6d… --- Mark Brown (2): kselftest/arm64: Increase frequency of signal delivery in fp-stress kselftest/arm64: Poll less often while waiting for fp-stress children tools/testing/selftests/arm64/fp/fp-stress.c | 28 +++++++++++++++++----------- 1 file changed, 17 insertions(+), 11 deletions(-) --- base-commit: 8e929cb546ee42c9a61d24fae60605e9e3192354 change-id: 20241028-arm64-fp-stress-interval-8f5e62c06e12 Best regards, -- Mark Brown <broonie(a)kernel.org>

11 months, 1 week

3
4
0 0

[PATCH bpf-next 1/2] libbpf: Add missing per-arch include path

by Björn Töpel

From: Björn Töpel <bjorn(a)rivosinc.com> libbpf does not include the per-arch tools include path, e.g. tools/arch/riscv/include. Some architectures depend those files to build properly. Include tools/arch/$(SUBARCH)/include in the libbpf build. Fixes: 6d74d178fe6e ("tools: Add riscv barrier implementation") Signed-off-by: Björn Töpel <bjorn(a)rivosinc.com> --- tools/lib/bpf/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile index 1b22f0f37288..857a5f7b413d 100644 --- a/tools/lib/bpf/Makefile +++ b/tools/lib/bpf/Makefile @@ -61,7 +61,8 @@ ifndef VERBOSE endif INCLUDES = -I$(or $(OUTPUT),.) \ - -I$(srctree)/tools/include -I$(srctree)/tools/include/uapi + -I$(srctree)/tools/include -I$(srctree)/tools/include/uapi \ + -I$(srctree)/tools/arch/$(SRCARCH)/include export prefix libdir src obj base-commit: db5ca265e3334b48c4e3fa07eef79e8bc578c430 -- 2.43.0

11 months, 1 week

5
11
0 0

[PATCH net-next v9] net: ipv4: Cache pmtu for all packet paths if multipath enabled

by Vladimir Vdovin

Check number of paths by fib_info_num_path(), and update_or_create_fnhe() for every path. Problem is that pmtu is cached only for the oif that has received icmp message "need to frag", other oifs will still try to use "default" iface mtu. An example topology showing the problem: | host1 +---------+ | dummy0 | 10.179.20.18/32 mtu9000 +---------+ +-----------+----------------+ +---------+ +---------+ | ens17f0 | 10.179.2.141/31 | ens17f1 | 10.179.2.13/31 +---------+ +---------+ | (all here have mtu 9000) | +------+ +------+ | ro1 | 10.179.2.140/31 | ro2 | 10.179.2.12/31 +------+ +------+ | | ---------+------------+-------------------+------ | +-----+ | ro3 | 10.10.10.10 mtu1500 +-----+ | ======================================== some networks ======================================== | +-----+ | eth0| 10.10.30.30 mtu9000 +-----+ | host2 host1 have enabled multipath and sysctl net.ipv4.fib_multipath_hash_policy = 1: default proto static src 10.179.20.18 nexthop via 10.179.2.12 dev ens17f1 weight 1 nexthop via 10.179.2.140 dev ens17f0 weight 1 When host1 tries to do pmtud from 10.179.20.18/32 to host2, host1 receives at ens17f1 iface an icmp packet from ro3 that ro3 mtu=1500. And host1 caches it in nexthop exceptions cache. Problem is that it is cached only for the iface that has received icmp, and there is no way that ro3 will send icmp msg to host1 via another path. Host1 now have this routes to host2: ip r g 10.10.30.30 sport 30000 dport 443 10.10.30.30 via 10.179.2.12 dev ens17f1 src 10.179.20.18 uid 0 cache expires 521sec mtu 1500 ip r g 10.10.30.30 sport 30033 dport 443 10.10.30.30 via 10.179.2.140 dev ens17f0 src 10.179.20.18 uid 0 cache So when host1 tries again to reach host2 with mtu>1500, if packet flow is lucky enough to be hashed with oif=ens17f1 its ok, if oif=ens17f0 it blackholes and still gets icmp msgs from ro3 to ens17f1, until lucky day when ro3 will send it through another flow to ens17f0. Signed-off-by: Vladimir Vdovin <deliran(a)verdict.gg> --- V9: selftests in pmtu.sh: - remove useless return - fix mtu var override V8: selftests in pmtu.sh: - Change var names from "dummy" to "host" - Fix errors caused by incorrect iface arguments pass - Add src addr to setup_multipath_new - Change multipath* func order - Change route_get_dst_exception() && route_get_dst_pmtu_from_exception() and arguments pass where they are used as Ido suggested in https://lore.kernel.org/all/ZykH_fdcMBdFgXix@shredder/ V7: selftest in pmtu.sh: - add setup_multipath() with old and new nh tests - add global "dummy_v4" addr variables - add documentation - remove dummy netdev usage in mp nh test - remove useless sysctl opts in mp nh test V6: - make commit message cleaner V5: - make self test cleaner V4: - fix selftest, do route lookup before checking cached exceptions V3: - add selftest - fix compile error V2: - fix fib_info_num_path parameter pass --- net/ipv4/route.c | 13 ++++ tools/testing/selftests/net/pmtu.sh | 117 ++++++++++++++++++++++++---- 2 files changed, 113 insertions(+), 17 deletions(-) diff --git a/net/ipv4/route.c b/net/ipv4/route.c index 723ac9181558..652f603d29fe 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -1027,6 +1027,19 @@ static void __ip_rt_update_pmtu(struct rtable *rt, struct flowi4 *fl4, u32 mtu) struct fib_nh_common *nhc; fib_select_path(net, &res, fl4, NULL); +#ifdef CONFIG_IP_ROUTE_MULTIPATH + if (fib_info_num_path(res.fi) > 1) { + int nhsel; + + for (nhsel = 0; nhsel < fib_info_num_path(res.fi); nhsel++) { + nhc = fib_info_nhc(res.fi, nhsel); + update_or_create_fnhe(nhc, fl4->daddr, 0, mtu, lock, + jiffies + net->ipv4.ip_rt_mtu_expires); + } + rcu_read_unlock(); + return; + } +#endif /* CONFIG_IP_ROUTE_MULTIPATH */ nhc = FIB_RES_NHC(res); update_or_create_fnhe(nhc, fl4->daddr, 0, mtu, lock, jiffies + net->ipv4.ip_rt_mtu_expires); diff --git a/tools/testing/selftests/net/pmtu.sh b/tools/testing/selftests/net/pmtu.sh index 569bce8b6383..611ae7862f46 100755 --- a/tools/testing/selftests/net/pmtu.sh +++ b/tools/testing/selftests/net/pmtu.sh @@ -197,6 +197,12 @@ # # - pmtu_ipv6_route_change # Same as above but with IPv6 +# +# - pmtu_ipv4_mp_exceptions +# Use the same topology as in pmtu_ipv4, but add routeable addresses +# on host A and B on lo reachable via both routers. Host A and B +# addresses have multipath routes to each other, b_r1 mtu = 1500. +# Check that PMTU exceptions are created for both paths. source lib.sh source net_helper.sh @@ -266,7 +272,8 @@ tests=" list_flush_ipv4_exception ipv4: list and flush cached exceptions 1 list_flush_ipv6_exception ipv6: list and flush cached exceptions 1 pmtu_ipv4_route_change ipv4: PMTU exception w/route replace 1 - pmtu_ipv6_route_change ipv6: PMTU exception w/route replace 1" + pmtu_ipv6_route_change ipv6: PMTU exception w/route replace 1 + pmtu_ipv4_mp_exceptions ipv4: PMTU multipath nh exceptions 1" # Addressing and routing for tests with routers: four network segments, with # index SEGMENT between 1 and 4, a common prefix (PREFIX4 or PREFIX6) and an @@ -343,6 +350,9 @@ tunnel6_a_addr="fd00:2::a" tunnel6_b_addr="fd00:2::b" tunnel6_mask="64" +host4_a_addr="192.168.99.99" +host4_b_addr="192.168.88.88" + dummy6_0_prefix="fc00:1000::" dummy6_1_prefix="fc00:1001::" dummy6_mask="64" @@ -984,6 +994,52 @@ setup_ovs_bridge() { run_cmd ip route add ${prefix6}:${b_r1}::1 via ${prefix6}:${a_r1}::2 } +setup_multipath_new() { + # Set up host A with multipath routes to host B host4_b_addr + run_cmd ${ns_a} ip addr add ${host4_a_addr} dev lo + run_cmd ${ns_a} ip nexthop add id 401 via ${prefix4}.${a_r1}.2 dev veth_A-R1 + run_cmd ${ns_a} ip nexthop add id 402 via ${prefix4}.${a_r2}.2 dev veth_A-R2 + run_cmd ${ns_a} ip nexthop add id 403 group 401/402 + run_cmd ${ns_a} ip route add ${host4_b_addr} src ${host4_a_addr} nhid 403 + + # Set up host B with multipath routes to host A host4_a_addr + run_cmd ${ns_b} ip addr add ${host4_b_addr} dev lo + run_cmd ${ns_b} ip nexthop add id 401 via ${prefix4}.${b_r1}.2 dev veth_B-R1 + run_cmd ${ns_b} ip nexthop add id 402 via ${prefix4}.${b_r2}.2 dev veth_B-R2 + run_cmd ${ns_b} ip nexthop add id 403 group 401/402 + run_cmd ${ns_b} ip route add ${host4_a_addr} src ${host4_b_addr} nhid 403 +} + +setup_multipath_old() { + # Set up host A with multipath routes to host B host4_b_addr + run_cmd ${ns_a} ip addr add ${host4_a_addr} dev lo + run_cmd ${ns_a} ip route add ${host4_b_addr} \ + src ${host4_a_addr} \ + nexthop via ${prefix4}.${a_r1}.2 weight 1 \ + nexthop via ${prefix4}.${a_r2}.2 weight 1 + + # Set up host B with multipath routes to host A host4_a_addr + run_cmd ${ns_b} ip addr add ${host4_b_addr} dev lo + run_cmd ${ns_b} ip route add ${host4_a_addr} \ + src ${host4_b_addr} \ + nexthop via ${prefix4}.${b_r1}.2 weight 1 \ + nexthop via ${prefix4}.${b_r2}.2 weight 1 +} + +setup_multipath() { + if [ "$USE_NH" = "yes" ]; then + setup_multipath_new + else + setup_multipath_old + fi + + # Set up routers with routes to dummies + run_cmd ${ns_r1} ip route add ${host4_a_addr} via ${prefix4}.${a_r1}.1 + run_cmd ${ns_r2} ip route add ${host4_a_addr} via ${prefix4}.${a_r2}.1 + run_cmd ${ns_r1} ip route add ${host4_b_addr} via ${prefix4}.${b_r1}.1 + run_cmd ${ns_r2} ip route add ${host4_b_addr} via ${prefix4}.${b_r2}.1 +} + setup() { [ "$(id -u)" -ne 0 ] && echo " need to run as root" && return $ksft_skip @@ -1076,23 +1132,15 @@ link_get_mtu() { } route_get_dst_exception() { - ns_cmd="${1}" - dst="${2}" - dsfield="${3}" - - if [ -z "${dsfield}" ]; then - dsfield=0 - fi + ns_cmd="${1}"; shift - ${ns_cmd} ip route get "${dst}" dsfield "${dsfield}" + ${ns_cmd} ip route get "$@" } route_get_dst_pmtu_from_exception() { - ns_cmd="${1}" - dst="${2}" - dsfield="${3}" + ns_cmd="${1}"; shift - mtu_parse "$(route_get_dst_exception "${ns_cmd}" "${dst}" "${dsfield}")" + mtu_parse "$(route_get_dst_exception "${ns_cmd}" "$@")" } check_pmtu_value() { @@ -1235,10 +1283,10 @@ test_pmtu_ipv4_dscp_icmp_exception() { run_cmd "${ns_a}" ping -q -M want -Q "${dsfield}" -c 1 -w 1 -s "${len}" "${dst2}" # Check that exceptions have been created with the correct PMTU - pmtu_1="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst1}" "${policy_mark}")" + pmtu_1="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst1}" dsfield "${policy_mark}")" check_pmtu_value "1400" "${pmtu_1}" "exceeding MTU" || return 1 - pmtu_2="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst2}" "${policy_mark}")" + pmtu_2="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst2}" dsfield "${policy_mark}")" check_pmtu_value "1500" "${pmtu_2}" "exceeding MTU" || return 1 } @@ -1285,9 +1333,9 @@ test_pmtu_ipv4_dscp_udp_exception() { UDP:"${dst2}":50000,tos="${dsfield}" # Check that exceptions have been created with the correct PMTU - pmtu_1="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst1}" "${policy_mark}")" + pmtu_1="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst1}" dsfield "${policy_mark}")" check_pmtu_value "1400" "${pmtu_1}" "exceeding MTU" || return 1 - pmtu_2="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst2}" "${policy_mark}")" + pmtu_2="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst2}" dsfield "${policy_mark}")" check_pmtu_value "1500" "${pmtu_2}" "exceeding MTU" || return 1 } @@ -2329,6 +2377,41 @@ test_pmtu_ipv6_route_change() { test_pmtu_ipvX_route_change 6 } +test_pmtu_ipv4_mp_exceptions() { + setup namespaces routing multipath || return $ksft_skip + + trace "${ns_a}" veth_A-R1 "${ns_r1}" veth_R1-A \ + "${ns_r1}" veth_R1-B "${ns_b}" veth_B-R1 \ + "${ns_a}" veth_A-R2 "${ns_r2}" veth_R2-A \ + "${ns_r2}" veth_R2-B "${ns_b}" veth_B-R2 + + # Set up initial MTU values + mtu "${ns_a}" veth_A-R1 2000 + mtu "${ns_r1}" veth_R1-A 2000 + mtu "${ns_r1}" veth_R1-B 1500 + mtu "${ns_b}" veth_B-R1 1500 + + mtu "${ns_a}" veth_A-R2 2000 + mtu "${ns_r2}" veth_R2-A 2000 + mtu "${ns_r2}" veth_R2-B 1500 + mtu "${ns_b}" veth_B-R2 1500 + + fail=0 + + # Ping and expect two nexthop exceptions for two routes in nh group + run_cmd ${ns_a} ping -q -M want -i 0.1 -c 1 -s 1800 "${host4_b_addr}" + + # Do route lookup before checking cached exceptions. + # The following commands are needed for dst entries to be cached + # in both paths exceptions and therefore dumped to user space + # Check that exceptions have been created with the correct PMTU + pmtu_a_R1="$(route_get_dst_pmtu_from_exception "${ns_a}" "${host4_b_addr}" oif veth_A-R1)" + pmtu_a_R2="$(route_get_dst_pmtu_from_exception "${ns_a}" "${host4_b_addr}" oif veth_A-R2)" + + check_pmtu_value "1500" "${pmtu_a_R1}" "exceeding MTU (veth_A-R2)" || return 1 + check_pmtu_value "1500" "${pmtu_a_R2}" "exceeding MTU (veth_A-R1)" || return 1 +} + usage() { echo echo "$0 [OPTIONS] [TEST]..." base-commit: 66600fac7a984dea4ae095411f644770b2561ede -- 2.43.5

11 months, 1 week

2
1
0 0

[PATCH net-next v8] net: ipv4: Cache pmtu for all packet paths if multipath enabled

by Vladimir Vdovin

Check number of paths by fib_info_num_path(), and update_or_create_fnhe() for every path. Problem is that pmtu is cached only for the oif that has received icmp message "need to frag", other oifs will still try to use "default" iface mtu. An example topology showing the problem: | host1 +---------+ | dummy0 | 10.179.20.18/32 mtu9000 +---------+ +-----------+----------------+ +---------+ +---------+ | ens17f0 | 10.179.2.141/31 | ens17f1 | 10.179.2.13/31 +---------+ +---------+ | (all here have mtu 9000) | +------+ +------+ | ro1 | 10.179.2.140/31 | ro2 | 10.179.2.12/31 +------+ +------+ | | ---------+------------+-------------------+------ | +-----+ | ro3 | 10.10.10.10 mtu1500 +-----+ | ======================================== some networks ======================================== | +-----+ | eth0| 10.10.30.30 mtu9000 +-----+ | host2 host1 have enabled multipath and sysctl net.ipv4.fib_multipath_hash_policy = 1: default proto static src 10.179.20.18 nexthop via 10.179.2.12 dev ens17f1 weight 1 nexthop via 10.179.2.140 dev ens17f0 weight 1 When host1 tries to do pmtud from 10.179.20.18/32 to host2, host1 receives at ens17f1 iface an icmp packet from ro3 that ro3 mtu=1500. And host1 caches it in nexthop exceptions cache. Problem is that it is cached only for the iface that has received icmp, and there is no way that ro3 will send icmp msg to host1 via another path. Host1 now have this routes to host2: ip r g 10.10.30.30 sport 30000 dport 443 10.10.30.30 via 10.179.2.12 dev ens17f1 src 10.179.20.18 uid 0 cache expires 521sec mtu 1500 ip r g 10.10.30.30 sport 30033 dport 443 10.10.30.30 via 10.179.2.140 dev ens17f0 src 10.179.20.18 uid 0 cache So when host1 tries again to reach host2 with mtu>1500, if packet flow is lucky enough to be hashed with oif=ens17f1 its ok, if oif=ens17f0 it blackholes and still gets icmp msgs from ro3 to ens17f1, until lucky day when ro3 will send it through another flow to ens17f0. Signed-off-by: Vladimir Vdovin <deliran(a)verdict.gg> --- V8: selftests in pmtu.sh: - Change var names from "dummy" to "host" - Fix errors caused by incorrect iface arguments pass - Add src addr to setup_multipath_new - Change multipath* func order - Change route_get_dst_exception() && route_get_dst_pmtu_from_exception() and arguments pass where they are used as Ido suggested in https://lore.kernel.org/all/ZykH_fdcMBdFgXix@shredder/ V7: selftest in pmtu.sh: - add setup_multipath() with old and new nh tests - add global "dummy_v4" addr variables - add documentation - remove dummy netdev usage in mp nh test - remove useless sysctl opts in mp nh test V6: - make commit message cleaner V5: - make self test cleaner V4: - fix selftest, do route lookup before checking cached exceptions V3: - add selftest - fix compile error V2: - fix fib_info_num_path parameter pass --- net/ipv4/route.c | 13 +++ tools/testing/selftests/net/pmtu.sh | 119 ++++++++++++++++++++++++---- 2 files changed, 115 insertions(+), 17 deletions(-) diff --git a/net/ipv4/route.c b/net/ipv4/route.c index 723ac9181558..652f603d29fe 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -1027,6 +1027,19 @@ static void __ip_rt_update_pmtu(struct rtable *rt, struct flowi4 *fl4, u32 mtu) struct fib_nh_common *nhc; fib_select_path(net, &res, fl4, NULL); +#ifdef CONFIG_IP_ROUTE_MULTIPATH + if (fib_info_num_path(res.fi) > 1) { + int nhsel; + + for (nhsel = 0; nhsel < fib_info_num_path(res.fi); nhsel++) { + nhc = fib_info_nhc(res.fi, nhsel); + update_or_create_fnhe(nhc, fl4->daddr, 0, mtu, lock, + jiffies + net->ipv4.ip_rt_mtu_expires); + } + rcu_read_unlock(); + return; + } +#endif /* CONFIG_IP_ROUTE_MULTIPATH */ nhc = FIB_RES_NHC(res); update_or_create_fnhe(nhc, fl4->daddr, 0, mtu, lock, jiffies + net->ipv4.ip_rt_mtu_expires); diff --git a/tools/testing/selftests/net/pmtu.sh b/tools/testing/selftests/net/pmtu.sh index 569bce8b6383..2b79a16d3369 100755 --- a/tools/testing/selftests/net/pmtu.sh +++ b/tools/testing/selftests/net/pmtu.sh @@ -197,6 +197,12 @@ # # - pmtu_ipv6_route_change # Same as above but with IPv6 +# +# - pmtu_ipv4_mp_exceptions +# Use the same topology as in pmtu_ipv4, but add routeable addresses +# on host A and B on lo reachable via both routers. Host A and B +# addresses have multipath routes to each other, b_r1 mtu = 1500. +# Check that PMTU exceptions are created for both paths. source lib.sh source net_helper.sh @@ -266,7 +272,8 @@ tests=" list_flush_ipv4_exception ipv4: list and flush cached exceptions 1 list_flush_ipv6_exception ipv6: list and flush cached exceptions 1 pmtu_ipv4_route_change ipv4: PMTU exception w/route replace 1 - pmtu_ipv6_route_change ipv6: PMTU exception w/route replace 1" + pmtu_ipv6_route_change ipv6: PMTU exception w/route replace 1 + pmtu_ipv4_mp_exceptions ipv4: PMTU multipath nh exceptions 1" # Addressing and routing for tests with routers: four network segments, with # index SEGMENT between 1 and 4, a common prefix (PREFIX4 or PREFIX6) and an @@ -343,6 +350,9 @@ tunnel6_a_addr="fd00:2::a" tunnel6_b_addr="fd00:2::b" tunnel6_mask="64" +host4_a_addr="192.168.99.99" +host4_b_addr="192.168.88.88" + dummy6_0_prefix="fc00:1000::" dummy6_1_prefix="fc00:1001::" dummy6_mask="64" @@ -984,6 +994,52 @@ setup_ovs_bridge() { run_cmd ip route add ${prefix6}:${b_r1}::1 via ${prefix6}:${a_r1}::2 } +setup_multipath_new() { + # Set up host A with multipath routes to host B host4_b_addr + run_cmd ${ns_a} ip addr add ${host4_a_addr} dev lo + run_cmd ${ns_a} ip nexthop add id 401 via ${prefix4}.${a_r1}.2 dev veth_A-R1 + run_cmd ${ns_a} ip nexthop add id 402 via ${prefix4}.${a_r2}.2 dev veth_A-R2 + run_cmd ${ns_a} ip nexthop add id 403 group 401/402 + run_cmd ${ns_a} ip route add ${host4_b_addr} src ${host4_a_addr} nhid 403 + + # Set up host B with multipath routes to host A host4_a_addr + run_cmd ${ns_b} ip addr add ${host4_b_addr} dev lo + run_cmd ${ns_b} ip nexthop add id 401 via ${prefix4}.${b_r1}.2 dev veth_B-R1 + run_cmd ${ns_b} ip nexthop add id 402 via ${prefix4}.${b_r2}.2 dev veth_B-R2 + run_cmd ${ns_b} ip nexthop add id 403 group 401/402 + run_cmd ${ns_b} ip route add ${host4_a_addr} src ${host4_b_addr} nhid 403 +} + +setup_multipath_old() { + # Set up host A with multipath routes to host B host4_b_addr + run_cmd ${ns_a} ip addr add ${host4_a_addr} dev lo + run_cmd ${ns_a} ip route add ${host4_b_addr} \ + src ${host4_a_addr} \ + nexthop via ${prefix4}.${a_r1}.2 weight 1 \ + nexthop via ${prefix4}.${a_r2}.2 weight 1 + + # Set up host B with multipath routes to host A host4_a_addr + run_cmd ${ns_b} ip addr add ${host4_b_addr} dev lo + run_cmd ${ns_b} ip route add ${host4_a_addr} \ + src ${host4_b_addr} \ + nexthop via ${prefix4}.${b_r1}.2 weight 1 \ + nexthop via ${prefix4}.${b_r2}.2 weight 1 +} + +setup_multipath() { + if [ "$USE_NH" = "yes" ]; then + setup_multipath_new + else + setup_multipath_old + fi + + # Set up routers with routes to dummies + run_cmd ${ns_r1} ip route add ${host4_a_addr} via ${prefix4}.${a_r1}.1 + run_cmd ${ns_r2} ip route add ${host4_a_addr} via ${prefix4}.${a_r2}.1 + run_cmd ${ns_r1} ip route add ${host4_b_addr} via ${prefix4}.${b_r1}.1 + run_cmd ${ns_r2} ip route add ${host4_b_addr} via ${prefix4}.${b_r2}.1 +} + setup() { [ "$(id -u)" -ne 0 ] && echo " need to run as root" && return $ksft_skip @@ -1076,23 +1132,15 @@ link_get_mtu() { } route_get_dst_exception() { - ns_cmd="${1}" - dst="${2}" - dsfield="${3}" - - if [ -z "${dsfield}" ]; then - dsfield=0 - fi + ns_cmd="${1}"; shift - ${ns_cmd} ip route get "${dst}" dsfield "${dsfield}" + ${ns_cmd} ip route get "$@" } route_get_dst_pmtu_from_exception() { - ns_cmd="${1}" - dst="${2}" - dsfield="${3}" + ns_cmd="${1}"; shift - mtu_parse "$(route_get_dst_exception "${ns_cmd}" "${dst}" "${dsfield}")" + mtu_parse "$(route_get_dst_exception "${ns_cmd}" "$@")" } check_pmtu_value() { @@ -1235,10 +1283,10 @@ test_pmtu_ipv4_dscp_icmp_exception() { run_cmd "${ns_a}" ping -q -M want -Q "${dsfield}" -c 1 -w 1 -s "${len}" "${dst2}" # Check that exceptions have been created with the correct PMTU - pmtu_1="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst1}" "${policy_mark}")" + pmtu_1="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst1}" dsfield "${policy_mark}")" check_pmtu_value "1400" "${pmtu_1}" "exceeding MTU" || return 1 - pmtu_2="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst2}" "${policy_mark}")" + pmtu_2="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst2}" dsfield "${policy_mark}")" check_pmtu_value "1500" "${pmtu_2}" "exceeding MTU" || return 1 } @@ -1285,9 +1333,9 @@ test_pmtu_ipv4_dscp_udp_exception() { UDP:"${dst2}":50000,tos="${dsfield}" # Check that exceptions have been created with the correct PMTU - pmtu_1="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst1}" "${policy_mark}")" + pmtu_1="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst1}" dsfield "${policy_mark}")" check_pmtu_value "1400" "${pmtu_1}" "exceeding MTU" || return 1 - pmtu_2="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst2}" "${policy_mark}")" + pmtu_2="$(route_get_dst_pmtu_from_exception "${ns_a}" "${dst2}" dsfield "${policy_mark}")" check_pmtu_value "1500" "${pmtu_2}" "exceeding MTU" || return 1 } @@ -2329,6 +2377,43 @@ test_pmtu_ipv6_route_change() { test_pmtu_ipvX_route_change 6 } +test_pmtu_ipv4_mp_exceptions() { + setup namespaces routing multipath || return $ksft_skip + + trace "${ns_a}" veth_A-R1 "${ns_r1}" veth_R1-A \ + "${ns_r1}" veth_R1-B "${ns_b}" veth_B-R1 \ + "${ns_a}" veth_A-R2 "${ns_r2}" veth_R2-A \ + "${ns_r2}" veth_R2-B "${ns_b}" veth_B-R2 + + # Set up initial MTU values + mtu "${ns_a}" veth_A-R1 2000 + mtu "${ns_r1}" veth_R1-A 2000 + mtu "${ns_r1}" veth_R1-B 1500 + mtu "${ns_b}" veth_B-R1 1500 + + mtu "${ns_a}" veth_A-R2 2000 + mtu "${ns_r2}" veth_R2-A 2000 + mtu "${ns_r2}" veth_R2-B 1500 + mtu "${ns_b}" veth_B-R2 1500 + + fail=0 + + # Ping and expect two nexthop exceptions for two routes in nh group + run_cmd ${ns_a} ping -q -M want -i 0.1 -c 1 -s 1800 "${host4_b_addr}" + + # Do route lookup before checking cached exceptions. + # The following commands are needed for dst entries to be cached + # in both paths exceptions and therefore dumped to user space + # Check that exceptions have been created with the correct PMTU + pmtu="$(route_get_dst_pmtu_from_exception "${ns_a}" "${host4_b_addr}" oif veth_A-R1)" + pmtu="$(route_get_dst_pmtu_from_exception "${ns_a}" "${host4_b_addr}" oif veth_A-R2)" + + check_pmtu_value "1500" "${pmtu}" "exceeding MTU (veth_A-R2)" || return 1 + check_pmtu_value "1500" "${pmtu}" "exceeding MTU (veth_A-R1)" || return 1 + + return ${fail} +} + usage() { echo echo "$0 [OPTIONS] [TEST]..." base-commit: 66600fac7a984dea4ae095411f644770b2561ede -- 2.43.5

11 months, 1 week

3
3
0 0

[PATCH] selftests: vDSO: Do not rely on $ARCH for vdso_test_getrandom && vdso_test_chacha

by Christophe Leroy

$ARCH is not always enough to know whether getrandom vDSO is supported or not. For instance on x86 we want it for x86_64 but not i386. On the other hand, we already have detailed architecture selection in vdso_config.h, the only difference is that it cannot be used for Makefile. But most selftests are built regardless of whether a functionality is supported or not. The return value KSFT_SKIP is there for than: it tells the test is skipped because it is not supported. Make the implementation more flexible by setting a VDSO_GETRANDOM macro in vdso_config.h. That macro contains the path to the file that defines __arch_chacha20_blocks_nostack(). It avoids the symbolic link to vdso directory and will allow architectures to have several implementations of __arch_chacha20_blocks_nostack() if needed. Then restore the original behaviour which was dedicated to vdso_standalone_test_x86 and build getrandom and chacha tests all the time just like other vDSO selftests and return SKIP when the functionality to be tested is not implemented. This has the advantage of doing architecture specific selection at only one place. Also change vdso_test_getrandom to return SKIP instead of FAIL when vDSO function is not found, just like vdso_test_getcpu or vdso_test_gettimeofday. Signed-off-by: Christophe Leroy <christophe.leroy(a)csgroup.eu> --- Based on latest random tree (0dfed8092247) tools/arch/x86/vdso | 1 - tools/testing/selftests/vDSO/Makefile | 10 ++++------ tools/testing/selftests/vDSO/vdso_config.h | 3 +++ tools/testing/selftests/vDSO/vdso_test_chacha-asm.S | 7 +++++++ tools/testing/selftests/vDSO/vdso_test_chacha.c | 11 +++++++++++ tools/testing/selftests/vDSO/vdso_test_getrandom.c | 2 +- 6 files changed, 26 insertions(+), 8 deletions(-) delete mode 120000 tools/arch/x86/vdso create mode 100644 tools/testing/selftests/vDSO/vdso_test_chacha-asm.S diff --git a/tools/arch/x86/vdso b/tools/arch/x86/vdso deleted file mode 120000 index 7eb962fd3454..000000000000 --- a/tools/arch/x86/vdso +++ /dev/null @@ -1 +0,0 @@ -../../../arch/x86/entry/vdso/ \ No newline at end of file diff --git a/tools/testing/selftests/vDSO/Makefile b/tools/testing/selftests/vDSO/Makefile index 5ead6b1f0478..cfb7c281b22c 100644 --- a/tools/testing/selftests/vDSO/Makefile +++ b/tools/testing/selftests/vDSO/Makefile @@ -1,6 +1,6 @@ # SPDX-License-Identifier: GPL-2.0 -ARCH ?= $(shell uname -m | sed -e s/i.86/x86/) -SRCARCH := $(subst x86_64,x86,$(ARCH)) +uname_M := $(shell uname -m 2>/dev/null || echo not) +ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/x86/ -e s/x86_64/x86/) TEST_GEN_PROGS := vdso_test_gettimeofday TEST_GEN_PROGS += vdso_test_getcpu @@ -10,10 +10,8 @@ ifeq ($(ARCH),$(filter $(ARCH),x86 x86_64)) TEST_GEN_PROGS += vdso_standalone_test_x86 endif TEST_GEN_PROGS += vdso_test_correctness -ifeq ($(ARCH),$(filter $(ARCH),x86_64)) TEST_GEN_PROGS += vdso_test_getrandom TEST_GEN_PROGS += vdso_test_chacha -endif CFLAGS := -std=gnu99 @@ -38,8 +36,8 @@ $(OUTPUT)/vdso_test_getrandom: CFLAGS += -isystem $(top_srcdir)/tools/include \ $(KHDR_INCLUDES) \ -isystem $(top_srcdir)/include/uapi -$(OUTPUT)/vdso_test_chacha: $(top_srcdir)/tools/arch/$(SRCARCH)/vdso/vgetrandom-chacha.S +$(OUTPUT)/vdso_test_chacha: vdso_test_chacha-asm.S $(OUTPUT)/vdso_test_chacha: CFLAGS += -idirafter $(top_srcdir)/tools/include \ - -idirafter $(top_srcdir)/arch/$(SRCARCH)/include \ + -idirafter $(top_srcdir)/arch/$(ARCH)/include \ -idirafter $(top_srcdir)/include \ -D__ASSEMBLY__ -Wa,--noexecstack diff --git a/tools/testing/selftests/vDSO/vdso_config.h b/tools/testing/selftests/vDSO/vdso_config.h index 740ce8c98d2e..693920471160 100644 --- a/tools/testing/selftests/vDSO/vdso_config.h +++ b/tools/testing/selftests/vDSO/vdso_config.h @@ -47,6 +47,7 @@ #elif defined(__x86_64__) #define VDSO_VERSION 0 #define VDSO_NAMES 1 +#define VDSO_GETRANDOM "../../../../arch/x86/entry/vdso/vgetrandom-chacha.S" #elif defined(__riscv__) || defined(__riscv) #define VDSO_VERSION 5 #define VDSO_NAMES 1 @@ -58,6 +59,7 @@ #define VDSO_NAMES 1 #endif +#ifndef __ASSEMBLY__ static const char *versions[7] = { "LINUX_2.6", "LINUX_2.6.15", @@ -88,5 +90,6 @@ static const char *names[2][7] = { "__vdso_getrandom", }, }; +#endif #endif /* __VDSO_CONFIG_H__ */ diff --git a/tools/testing/selftests/vDSO/vdso_test_chacha-asm.S b/tools/testing/selftests/vDSO/vdso_test_chacha-asm.S new file mode 100644 index 000000000000..8e704165f6f2 --- /dev/null +++ b/tools/testing/selftests/vDSO/vdso_test_chacha-asm.S @@ -0,0 +1,7 @@ +#include "vdso_config.h" + +#ifdef VDSO_GETRANDOM + +#include VDSO_GETRANDOM + +#endif diff --git a/tools/testing/selftests/vDSO/vdso_test_chacha.c b/tools/testing/selftests/vDSO/vdso_test_chacha.c index 3a5a08d857cf..9d18d49a82f8 100644 --- a/tools/testing/selftests/vDSO/vdso_test_chacha.c +++ b/tools/testing/selftests/vDSO/vdso_test_chacha.c @@ -8,6 +8,8 @@ #include <string.h> #include <stdint.h> #include <stdbool.h> +#include <linux/kconfig.h> +#include "vdso_config.h" #include "../kselftest.h" static uint32_t rol32(uint32_t word, unsigned int shift) @@ -57,6 +59,10 @@ typedef uint32_t u32; typedef uint64_t u64; #include <vdso/getrandom.h> +#ifdef VDSO_GETRANDOM +#define HAVE_VDSO_GETRANDOM 1 +#endif + int main(int argc, char *argv[]) { enum { TRIALS = 1000, BLOCKS = 128, BLOCK_SIZE = 64 }; @@ -68,6 +74,11 @@ int main(int argc, char *argv[]) ksft_print_header(); ksft_set_plan(1); + if (!__is_defined(HAVE_VDSO_GETRANDOM)) { + printf("__arch_chacha20_blocks_nostack() not implemented\n"); + return KSFT_SKIP; + } + for (unsigned int trial = 0; trial < TRIALS; ++trial) { if (getrandom(key, sizeof(key), 0) != sizeof(key)) { printf("getrandom() failed!\n"); diff --git a/tools/testing/selftests/vDSO/vdso_test_getrandom.c b/tools/testing/selftests/vDSO/vdso_test_getrandom.c index 8866b65a4605..47ee94b32617 100644 --- a/tools/testing/selftests/vDSO/vdso_test_getrandom.c +++ b/tools/testing/selftests/vDSO/vdso_test_getrandom.c @@ -115,7 +115,7 @@ static void vgetrandom_init(void) vgrnd.fn = (__typeof__(vgrnd.fn))vdso_sym(version, name); if (!vgrnd.fn) { printf("%s is missing!\n", name); - exit(KSFT_FAIL); + exit(KSFT_SKIP); } ret = VDSO_CALL(vgrnd.fn, 5, NULL, 0, 0, &vgrnd.params, ~0UL); if (ret == -ENOSYS) { -- 2.44.0

11 months, 1 week

5
15
0 0

[PATCH net-next] selftests: wireguards: use nft by default

by Hangbin Liu

Use nft by default if it's supported, as nft is the replacement for iptables, which is used by default in some releases. Additionally, iptables is dropped in some releases. Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com> --- CC nft developers to see if there are any easier configurations, as I'm not very familiar with nft commands. --- tools/testing/selftests/wireguard/netns.sh | 63 ++++++++++++++++++---- 1 file changed, 53 insertions(+), 10 deletions(-) diff --git a/tools/testing/selftests/wireguard/netns.sh b/tools/testing/selftests/wireguard/netns.sh index 405ff262ca93..4e29c1a7003c 100755 --- a/tools/testing/selftests/wireguard/netns.sh +++ b/tools/testing/selftests/wireguard/netns.sh @@ -44,6 +44,7 @@ sleep() { read -t "$1" -N 1 || true; } waitiperf() { pretty "${1//*-}" "wait for iperf:${3:-5201} pid $2"; while [[ $(ss -N "$1" -tlpH "sport = ${3:-5201}") != *\"iperf3\",pid=$2,fd=* ]]; do sleep 0.1; done; } waitncatudp() { pretty "${1//*-}" "wait for udp:1111 pid $2"; while [[ $(ss -N "$1" -ulpH 'sport = 1111') != *\"ncat\",pid=$2,fd=* ]]; do sleep 0.1; done; } waitiface() { pretty "${1//*-}" "wait for $2 to come up"; ip netns exec "$1" bash -c "while [[ \$(< \"/sys/class/net/$2/operstate\") != up ]]; do read -t .1 -N 0 || true; done;"; } +use_nft() { nft --version &> /dev/null; } cleanup() { set +e @@ -196,13 +197,23 @@ ip1 link set wg0 mtu 1300 ip2 link set wg0 mtu 1300 n1 wg set wg0 peer "$pub2" endpoint 127.0.0.1:2 n2 wg set wg0 peer "$pub1" endpoint 127.0.0.1:1 -n0 iptables -A INPUT -m length --length 1360 -j DROP +if use_nft; then + n0 nft add table inet filter + n0 nft add chain inet filter INPUT { type filter hook input priority filter \; policy accept \; } + n0 nft add rule inet filter INPUT meta length 1360 counter drop +else + n0 iptables -A INPUT -m length --length 1360 -j DROP +fi n1 ip route add 192.168.241.2/32 dev wg0 mtu 1299 n2 ip route add 192.168.241.1/32 dev wg0 mtu 1299 n2 ping -c 1 -W 1 -s 1269 192.168.241.1 n2 ip route delete 192.168.241.1/32 dev wg0 mtu 1299 n1 ip route delete 192.168.241.2/32 dev wg0 mtu 1299 -n0 iptables -F INPUT +if use_nft; then + n0 nft delete table inet filter +else + n0 iptables -F INPUT +fi ip1 link set wg0 mtu $orig_mtu ip2 link set wg0 mtu $orig_mtu @@ -334,7 +345,13 @@ waitiface $netns2 veths n0 bash -c 'printf 1 > /proc/sys/net/ipv4/ip_forward' n0 bash -c 'printf 2 > /proc/sys/net/netfilter/nf_conntrack_udp_timeout' n0 bash -c 'printf 2 > /proc/sys/net/netfilter/nf_conntrack_udp_timeout_stream' -n0 iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d 10.0.0.0/24 -j SNAT --to 10.0.0.1 +if use_nft; then + n0 nft add table inet nat + n0 nft add chain inet nat POSTROUTING { type nat hook postrouting priority srcnat\; policy accept \; } + n0 nft add rule inet nat POSTROUTING ip saddr 192.168.1.0/24 ip daddr 10.0.0.0/24 counter snat to 10.0.0.1 +else + n0 iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d 10.0.0.0/24 -j SNAT --to 10.0.0.1 +fi n1 wg set wg0 peer "$pub2" endpoint 10.0.0.100:2 persistent-keepalive 1 n1 ping -W 1 -c 1 192.168.241.2 @@ -348,10 +365,20 @@ n1 wg set wg0 peer "$pub2" persistent-keepalive 0 # Test that sk_bound_dev_if works n1 ping -I wg0 -c 1 -W 1 192.168.241.2 # What about when the mark changes and the packet must be rerouted? -n1 iptables -t mangle -I OUTPUT -j MARK --set-xmark 1 +if use_nft; then + n1 nft add table inet mangle + n1 nft add chain inet mangle OUTPUT { type route hook output priority mangle\; policy accept \; } + n1 nft add rule inet mangle OUTPUT counter meta mark set 0x1 +else + n1 iptables -t mangle -I OUTPUT -j MARK --set-xmark 1 +fi n1 ping -c 1 -W 1 192.168.241.2 # First the boring case n1 ping -I wg0 -c 1 -W 1 192.168.241.2 # Then the sk_bound_dev_if case -n1 iptables -t mangle -D OUTPUT -j MARK --set-xmark 1 +if use_nft; then + n1 nft delete table inet mangle +else + n1 iptables -t mangle -D OUTPUT -j MARK --set-xmark 1 +fi # Test that onion routing works, even when it loops n1 wg set wg0 peer "$pub3" allowed-ips 192.168.242.2/32 endpoint 192.168.241.2:5 @@ -385,16 +412,32 @@ n1 ping -W 1 -c 100 -f 192.168.99.7 n1 ping -W 1 -c 100 -f abab::1111 # Have ns2 NAT into wg0 packets from ns0, but return an icmp error along the right route. -n2 iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -d 192.168.241.0/24 -j SNAT --to 192.168.241.2 -n0 iptables -t filter -A INPUT \! -s 10.0.0.0/24 -i vethrs -j DROP # Manual rpfilter just to be explicit. +if use_nft; then + n2 nft add table inet nat + n2 nft add chain inet nat POSTROUTING { type nat hook postrouting priority srcnat\; policy accept \; } + n2 nft add rule inet nat POSTROUTING ip saddr 10.0.0.0/24 ip daddr 192.168.241.0/24 counter snat to 192.168.241.2 + + n0 nft add table inet filter + n0 nft add chain inet filter INPUT { type filter hook input priority filter \; policy accept \; } + n0 nft add rule inet filter INPUT iifname "vethrs" ip saddr != 10.0.0.0/24 counter drop +else + n2 iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -d 192.168.241.0/24 -j SNAT --to 192.168.241.2 + n0 iptables -t filter -A INPUT \! -s 10.0.0.0/24 -i vethrs -j DROP # Manual rpfilter just to be explicit. +fi n2 bash -c 'printf 1 > /proc/sys/net/ipv4/ip_forward' ip0 -4 route add 192.168.241.1 via 10.0.0.100 n2 wg set wg0 peer "$pub1" remove [[ $(! n0 ping -W 1 -c 1 192.168.241.1 || false) == *"From 10.0.0.100 icmp_seq=1 Destination Host Unreachable"* ]] -n0 iptables -t nat -F -n0 iptables -t filter -F -n2 iptables -t nat -F +if use_nft; then + n0 nft delete table inet nat + n0 nft delete table inet filter + n2 nft delete table inet nat +else + n0 iptables -t nat -F + n0 iptables -t filter -F + n2 iptables -t nat -F +fi ip0 link del vethrc ip0 link del vethrs ip1 link del wg0 -- 2.46.0

11 months, 1 week

2
1
0 0

[PATCH v2 net-next 0/2] ipv6: fix hangup on device removal

by Paolo Abeni

This addresses the infamous unregister_netdevice splat in net selftests; the actual fix is carried by the first patch, while the 2nd one addresses a related problem in the relevant test that was patially hiding the problem. Targeting net-next as the issue is quite old and I feel a little lost in the fib info/nh jungle. --- v1 -> v2: - drop unintended whitespace change in patch 1/2 Paolo Abeni (2): ipv6: release nexthop on device removal selftests: net: really check for bg process completion net/ipv6/route.c | 6 +++--- tools/testing/selftests/net/pmtu.sh | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) -- 2.45.2

11 months, 1 week

4
7
0 0

[PATCH v4 0/2] kselftest: tmpfs: Add ksft macros and skip if no root

by Shivam Chaudhary

This version 4 patch series replace direct error handling methods with ksft macros, which provide better reporting.Currently, when the tmpfs test runs, it does not display any output if it passes,and if it fails (particularly when not run as root),it simply exits without any warning or message. This series of patch adds: 1. Add 'ksft_print_header()' and 'ksft_set_plan()' to structure test outputs more effectively. 2. Skip if not run as root. 3. Replace direct error handling with 'ksft_test_result_*', 'ksft_print_msg' and KSFT_SKIP macros for better reporting. v3->v4: - Start a patchset - Split patch into smaller pathes to make it easy to review. Patch1 Replace 'ksft_test_result_skip' with 'KSFT_SKIP' during root run check. Patch2 Replace 'ksft_test_result_fail' with 'KSFT_SKIP' where fail does not make sense, or failure could be due to not unsupported APIs with appropriate warnings. v3: https://lore.kernel.org/all/20241028185756.111832-1-cvam0000@gmail.com/ v2->v3: - Remove extra ksft_set_plan() - Remove function for unshare() - Fix the comment style v2: https://lore.kernel.org/all/20241026191621.2860376-1-cvam0000@gmail.com/ v1->v2: - Make the commit message more clear. v1: https://lore.kernel.org/all/20241024200228.1075840-1-cvam0000@gmail.com/T/#u thanks Shivam Shivam Chaudhary (2): selftests:tmpfs: Add Skip test if not run as root selftests:tmpfs: Add kselftest support to tmpfs .../selftests/tmpfs/bug-link-o-tmpfile.c | 79 +++++++++++++++---- 1 file changed, 62 insertions(+), 17 deletions(-) -- 2.45.2

11 months, 1 week

2
4
0 0

[PATCH net-next v7] net: ipv4: Cache pmtu for all packet paths if multipath enabled

by Vladimir Vdovin

Check number of paths by fib_info_num_path(), and update_or_create_fnhe() for every path. Problem is that pmtu is cached only for the oif that has received icmp message "need to frag", other oifs will still try to use "default" iface mtu. An example topology showing the problem: | host1 +---------+ | dummy0 | 10.179.20.18/32 mtu9000 +---------+ +-----------+----------------+ +---------+ +---------+ | ens17f0 | 10.179.2.141/31 | ens17f1 | 10.179.2.13/31 +---------+ +---------+ | (all here have mtu 9000) | +------+ +------+ | ro1 | 10.179.2.140/31 | ro2 | 10.179.2.12/31 +------+ +------+ | | ---------+------------+-------------------+------ | +-----+ | ro3 | 10.10.10.10 mtu1500 +-----+ | ======================================== some networks ======================================== | +-----+ | eth0| 10.10.30.30 mtu9000 +-----+ | host2 host1 have enabled multipath and sysctl net.ipv4.fib_multipath_hash_policy = 1: default proto static src 10.179.20.18 nexthop via 10.179.2.12 dev ens17f1 weight 1 nexthop via 10.179.2.140 dev ens17f0 weight 1 When host1 tries to do pmtud from 10.179.20.18/32 to host2, host1 receives at ens17f1 iface an icmp packet from ro3 that ro3 mtu=1500. And host1 caches it in nexthop exceptions cache. Problem is that it is cached only for the iface that has received icmp, and there is no way that ro3 will send icmp msg to host1 via another path. Host1 now have this routes to host2: ip r g 10.10.30.30 sport 30000 dport 443 10.10.30.30 via 10.179.2.12 dev ens17f1 src 10.179.20.18 uid 0 cache expires 521sec mtu 1500 ip r g 10.10.30.30 sport 30033 dport 443 10.10.30.30 via 10.179.2.140 dev ens17f0 src 10.179.20.18 uid 0 cache So when host1 tries again to reach host2 with mtu>1500, if packet flow is lucky enough to be hashed with oif=ens17f1 its ok, if oif=ens17f0 it blackholes and still gets icmp msgs from ro3 to ens17f1, until lucky day when ro3 will send it through another flow to ens17f0. Signed-off-by: Vladimir Vdovin <deliran(a)verdict.gg> --- V7: selftest in pmtu.sh: - add setup_multipath() with old and new nh tests - add global "dummy_v4" addr variables - add documentation - remove dummy netdev usage in mp nh test - remove useless sysctl opts in mp nh test V6: - make commit message cleaner V5: - make self test cleaner V4: - fix selftest, do route lookup before checking cached exceptions V3: - add selftest - fix compile error V2: - fix fib_info_num_path parameter pass --- net/ipv4/route.c | 13 ++++ tools/testing/selftests/net/pmtu.sh | 95 ++++++++++++++++++++++++++++- 2 files changed, 107 insertions(+), 1 deletion(-) diff --git a/net/ipv4/route.c b/net/ipv4/route.c index 723ac9181558..652f603d29fe 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -1027,6 +1027,19 @@ static void __ip_rt_update_pmtu(struct rtable *rt, struct flowi4 *fl4, u32 mtu) struct fib_nh_common *nhc; fib_select_path(net, &res, fl4, NULL); +#ifdef CONFIG_IP_ROUTE_MULTIPATH + if (fib_info_num_path(res.fi) > 1) { + int nhsel; + + for (nhsel = 0; nhsel < fib_info_num_path(res.fi); nhsel++) { + nhc = fib_info_nhc(res.fi, nhsel); + update_or_create_fnhe(nhc, fl4->daddr, 0, mtu, lock, + jiffies + net->ipv4.ip_rt_mtu_expires); + } + rcu_read_unlock(); + return; + } +#endif /* CONFIG_IP_ROUTE_MULTIPATH */ nhc = FIB_RES_NHC(res); update_or_create_fnhe(nhc, fl4->daddr, 0, mtu, lock, jiffies + net->ipv4.ip_rt_mtu_expires); diff --git a/tools/testing/selftests/net/pmtu.sh b/tools/testing/selftests/net/pmtu.sh index 569bce8b6383..f24c84184c61 100755 --- a/tools/testing/selftests/net/pmtu.sh +++ b/tools/testing/selftests/net/pmtu.sh @@ -197,6 +197,12 @@ # # - pmtu_ipv6_route_change # Same as above but with IPv6 +# +# - pmtu_ipv4_mp_exceptions +# Use the same topology as in pmtu_ipv4, but add routeable "dummy" +# addresses on host A and B on lo0 reachable via both routers. +# Host A and B "dummy" addresses have multipath routes to each other. +# Check that PMTU exceptions are created for both paths. source lib.sh source net_helper.sh @@ -266,7 +272,8 @@ tests=" list_flush_ipv4_exception ipv4: list and flush cached exceptions 1 list_flush_ipv6_exception ipv6: list and flush cached exceptions 1 pmtu_ipv4_route_change ipv4: PMTU exception w/route replace 1 - pmtu_ipv6_route_change ipv6: PMTU exception w/route replace 1" + pmtu_ipv6_route_change ipv6: PMTU exception w/route replace 1 + pmtu_ipv4_mp_exceptions ipv4: PMTU multipath nh exceptions 1" # Addressing and routing for tests with routers: four network segments, with # index SEGMENT between 1 and 4, a common prefix (PREFIX4 or PREFIX6) and an @@ -343,6 +350,9 @@ tunnel6_a_addr="fd00:2::a" tunnel6_b_addr="fd00:2::b" tunnel6_mask="64" +dummy4_a_addr="192.168.99.99" +dummy4_b_addr="192.168.88.88" + dummy6_0_prefix="fc00:1000::" dummy6_1_prefix="fc00:1001::" dummy6_mask="64" @@ -984,6 +994,50 @@ setup_ovs_bridge() { run_cmd ip route add ${prefix6}:${b_r1}::1 via ${prefix6}:${a_r1}::2 } +setup_multipath() { + if [ "$USE_NH" = "yes" ]; then + setup_multipath_new + else + setup_multipath_old + fi + + # Set up routers with routes to dummies + run_cmd ${ns_r1} ip route add ${dummy4_a_addr} via ${prefix4}.${a_r1}.1 + run_cmd ${ns_r2} ip route add ${dummy4_a_addr} via ${prefix4}.${a_r2}.1 + run_cmd ${ns_r1} ip route add ${dummy4_b_addr} via ${prefix4}.${b_r1}.1 + run_cmd ${ns_r2} ip route add ${dummy4_b_addr} via ${prefix4}.${b_r2}.1 +} + +setup_multipath_new() { + # Set up host A with multipath routes to host B dummy4_b_addr + run_cmd ${ns_a} ip addr add ${dummy4_a_addr} dev lo0 + run_cmd ${ns_a} ip nexthop add id 201 via ${prefix4}.${a_r1}.2 dev veth_A-R1 + run_cmd ${ns_a} ip nexthop add id 202 via ${prefix4}.${a_r2}.2 dev veth_A-R2 + run_cmd ${ns_a} ip nexthop add id 203 group 201/202 + run_cmd ${ns_a} ip route add ${dummy4_b_addr} nhid 203 + + # Set up host B with multipath routes to host A dummy4_a_addr + run_cmd ${ns_b} ip addr add ${dummy4_b_addr} dev lo0 + run_cmd ${ns_b} ip nexthop add id 201 via ${prefix4}.${b_r1}.2 dev veth_A-R1 + run_cmd ${ns_b} ip nexthop add id 202 via ${prefix4}.${b_r2}.2 dev veth_A-R2 + run_cmd ${ns_b} ip nexthop add id 203 group 201/202 + run_cmd ${ns_b} ip route add ${dummy4_a_addr} nhid 203 +} + +setup_multipath_old() { + # Set up host A with multipath routes to host B dummy4_b_addr + run_cmd ${ns_a} ip addr add ${dummy4_a_addr} dev lo0 + run_cmd ${ns_a} ip route add ${dummy4_b_addr} \ + nexthop via ${prefix4}.${a_r1}.2 weight 1 \ + nexthop via ${prefix4}.${a_r2}.2 weight 1 + + # Set up host B with multipath routes to host A dummy4_a_addr + run_cmd ${ns_b} ip addr add ${dummy4_b_addr} dev lo0 + run_cmd ${ns_a} ip route add ${dummy4_a_addr} \ + nexthop via ${prefix4}.${a_b1}.2 weight 1 \ + nexthop via ${prefix4}.${a_b2}.2 weight 1 +} + setup() { [ "$(id -u)" -ne 0 ] && echo " need to run as root" && return $ksft_skip @@ -2329,6 +2383,45 @@ test_pmtu_ipv6_route_change() { test_pmtu_ipvX_route_change 6 } +test_pmtu_ipv4_mp_exceptions() { + setup namespaces routing multipath || return $ksft_skip + + trace "${ns_a}" veth_A-R1 "${ns_r1}" veth_R1-A \ + "${ns_r1}" veth_R1-B "${ns_b}" veth_B-R1 \ + "${ns_a}" veth_A-R2 "${ns_r2}" veth_R2-A \ + "${ns_r2}" veth_R2-B "${ns_b}" veth_B-R2 + + # Set up initial MTU values + mtu "${ns_a}" veth_A-R1 2000 + mtu "${ns_r1}" veth_R1-A 2000 + mtu "${ns_r1}" veth_R1-B 1400 + mtu "${ns_b}" veth_B-R1 1400 + + mtu "${ns_a}" veth_A-R2 2000 + mtu "${ns_r2}" veth_R2-A 2000 + mtu "${ns_r2}" veth_R2-B 1500 + mtu "${ns_b}" veth_B-R2 1500 + + fail=0 + + # Ping and expect two nexthop exceptions for two routes in nh group + run_cmd ${ns_a} ping -q -M want -i 0.1 -c 1 -s 1800 "${dummy4_b_addr}" + + # Do route lookup before checking cached exceptions. + # The following commands are needed for dst entries to be cached + # in both paths exceptions and therefore dumped to user space + run_cmd ${ns_a} ip route get ${dummy4_b_addr} oif veth_A-R1 + run_cmd ${ns_a} ip route get ${dummy4_b_addr} oif veth_A-R2 + + # Check cached exceptions + if [ "$(${ns_a} ip -oneline route list cache | grep mtu | wc -l)" -ne 2 ]; then + err " there are not enough cached exceptions" + fail=1 + fi + + return ${fail} +} + usage() { echo echo "$0 [OPTIONS] [TEST]..." base-commit: 66600fac7a984dea4ae095411f644770b2561ede -- 2.43.5

11 months, 1 week

3
3
0 0

[PATCH 0/6] kselftest/arm64: Test floating point signal context restore in fp-stress

by Mark Brown

Currently we test signal delivery to the programs run by fp-stress but our signal handlers simply count the number of signals seen and don't do anything with the floating point state. The original fpsimd-test and sve-test programs had signal handlers called irritators which modify the live register state, verifying that we restore the signal context on return, but a combination of misleading comments and code resulted in them never being used and the equivalent handlers in the other tests being stubbed or omitted. Clarify the code, implement effective irritator handlers for the test programs that can have them and then switch the signals generated by the fp-stress program over to use the irritators, ensuring that we validate that we restore the saved signal context properly. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- Mark Brown (6): kselftest/arm64: Correct misleading comments on fp-stress irritators kselftest/arm64: Remove unused ADRs from irritator handlers kselftest/arm64: Corrupt P15 in the irritator when testing SSVE kselftest/arm64: Implement irritators for ZA and ZT kselftest/arm64: Provide a SIGUSR1 handler in the kernel mode FP stress test kselftest/arm64: Test signal handler state modification in fp-stress tools/testing/selftests/arm64/fp/fp-stress.c | 2 +- tools/testing/selftests/arm64/fp/fpsimd-test.S | 4 +--- tools/testing/selftests/arm64/fp/kernel-test.c | 4 ++++ tools/testing/selftests/arm64/fp/sve-test.S | 6 ++---- tools/testing/selftests/arm64/fp/za-test.S | 13 ++++--------- tools/testing/selftests/arm64/fp/zt-test.S | 13 ++++--------- 6 files changed, 16 insertions(+), 26 deletions(-) --- base-commit: 8e929cb546ee42c9a61d24fae60605e9e3192354 change-id: 20241023-arm64-fp-stress-irritator-5415fe92adef Best regards, -- Mark Brown <broonie(a)kernel.org>

11 months, 1 week

2
15
0 0

Re: [PATCH v2 2/9] initramfs_test: kunit tests for initramfs unpacking

by David Disseldorp

[adding kunit lists to cc, see lore link below for context] https://lore.kernel.org/linux-fsdevel/20241104141750.16119-3-ddiss@suse.de/ On Wed, 6 Nov 2024 07:04:21 +0800, kernel test robot wrote: ... > All warnings (new ones prefixed by >>, old ones prefixed by <<): > > >> WARNING: modpost: vmlinux: section mismatch in reference: initramfs_test_cases+0x0 (section: .data) -> initramfs_test_extract (section: .init.text) > >> WARNING: modpost: vmlinux: section mismatch in reference: initramfs_test_cases+0x30 (section: .data) -> initramfs_test_fname_overrun (section: .init.text) > >> WARNING: modpost: vmlinux: section mismatch in reference: initramfs_test_cases+0x60 (section: .data) -> initramfs_test_data (section: .init.text) > >> WARNING: modpost: vmlinux: section mismatch in reference: initramfs_test_cases+0x90 (section: .data) -> initramfs_test_csum (section: .init.text) > >> WARNING: modpost: vmlinux: section mismatch in reference: initramfs_test_cases+0xc0 (section: .data) -> initramfs_test_hardlink (section: .init.text) > >> WARNING: modpost: vmlinux: section mismatch in reference: initramfs_test_cases+0xf0 (section: .data) -> initramfs_test_many (section: .init.text) If I understand correctly, the kunit_case initramfs_test_cases[] members can't be flagged __initdata, as they need to be present post-init for results queries via debugfs. The remaining -Wimplicit-function-declaration reports are all valid. I'll fix them in v3. Thanks, David

11 months, 1 week

1
0
0 0

[PATCH] selftests/ftrace: update kprobe syntax error test for ppc64le

by Hari Bathini

For ppc64le, depending on the kernel configuration used, offset 16 from function start address can also be considered function entry. Update the test case to accommodate such configurations. Signed-off-by: Hari Bathini <hbathini(a)linux.ibm.com> --- .../selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc index a16c6a6f6055..c03b94cc5784 100644 --- a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc +++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc @@ -111,7 +111,11 @@ check_error 'p vfs_read $arg* ^$arg*' # DOUBLE_ARGS if !grep -q 'kernel return probes support:' README; then check_error 'r vfs_read ^$arg*' # NOFENTRY_ARGS fi +if [ "$(uname -m)" = "ppc64le" ]; then +check_error 'p vfs_read+20 ^$arg*' # NOFENTRY_ARGS +else check_error 'p vfs_read+8 ^$arg*' # NOFENTRY_ARGS +fi check_error 'p vfs_read ^hoge' # NO_BTFARG check_error 'p kfree ^$arg10' # NO_BTFARG (exceed the number of parameters) check_error 'r kfree ^$retval' # NO_RETVAL -- 2.47.0

11 months, 1 week

4
14
0 0

[PATCH net-next] selftests: net: include lib/sh/*.sh with lib.sh

by Matthieu Baerts (NGI0)

Recently, the net/lib.sh file has been modified to include defer.sh from net/lib/sh/ directory. The Makefile from net/lib has been modified accordingly, but not the ones from the sub-targets using net/lib.sh. Because of that, the new file is not installed as expected when installing the Forwarding, MPTCP, and Netfilter targets, e.g. # make -C tools/testing/selftests TARGETS=net/mptcp install \ INSTALL_PATH=/tmp/kself # cd /tmp/kself/ # ./run_kselftest.sh -c net/mptcp TAP version 13 1..7 # timeout set to 1800 # selftests: net/mptcp: mptcp_connect.sh # ./../lib.sh: line 5: /tmp/kself/net/lib/sh/defer.sh: No such file or directory # (...) This can be fixed simply by adding all the .sh files from net/lib/sh directory to the TEST_INCLUDES variable in the different Makefile's. Fixes: a6e263f125cd ("selftests: net: lib: Introduce deferred commands") Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- tools/testing/selftests/net/forwarding/Makefile | 3 ++- tools/testing/selftests/net/mptcp/Makefile | 2 +- tools/testing/selftests/net/netfilter/Makefile | 3 ++- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/tools/testing/selftests/net/forwarding/Makefile b/tools/testing/selftests/net/forwarding/Makefile index 224346426ef2220470bf2dbef66198eae9331f56..7d885cff8d79bc6882d2341d0a1a59891fc1cb2e 100644 --- a/tools/testing/selftests/net/forwarding/Makefile +++ b/tools/testing/selftests/net/forwarding/Makefile @@ -126,6 +126,7 @@ TEST_FILES := devlink_lib.sh \ tc_common.sh TEST_INCLUDES := \ - ../lib.sh + ../lib.sh \ + $(wildcard ../lib/sh/*.sh) include ../../lib.mk diff --git a/tools/testing/selftests/net/mptcp/Makefile b/tools/testing/selftests/net/mptcp/Makefile index 5d796622e73099d0a0331c1bc8a41f09e1d36b4d..8e3fc05a539797c5e0feab72be69db623ef3fa96 100644 --- a/tools/testing/selftests/net/mptcp/Makefile +++ b/tools/testing/selftests/net/mptcp/Makefile @@ -11,7 +11,7 @@ TEST_GEN_FILES = mptcp_connect pm_nl_ctl mptcp_sockopt mptcp_inq TEST_FILES := mptcp_lib.sh settings -TEST_INCLUDES := ../lib.sh ../net_helper.sh +TEST_INCLUDES := ../lib.sh $(wildcard ../lib/sh/*.sh) ../net_helper.sh EXTRA_CLEAN := *.pcap diff --git a/tools/testing/selftests/net/netfilter/Makefile b/tools/testing/selftests/net/netfilter/Makefile index 542f7886a0bc2ac016f41d8b70357a8e0c1d271b..9d009f74cfc2da66428b1e23d5884e2c3bc4a85d 100644 --- a/tools/testing/selftests/net/netfilter/Makefile +++ b/tools/testing/selftests/net/netfilter/Makefile @@ -55,4 +55,5 @@ TEST_FILES := lib.sh TEST_FILES += packetdrill TEST_INCLUDES := \ - ../lib.sh + ../lib.sh \ + $(wildcard ../lib/sh/*.sh) --- base-commit: ecf99864ea6b1843773589a935bb026951bf12dd change-id: 20241104-net-next-selftests-lib-sh-deps-cc359ca5602f Best regards, -- Matthieu Baerts (NGI0) <matttbe(a)kernel.org>

11 months, 1 week

3
2
0 0

[PATCH bpf-next/net v3] selftests/bpf: Drop netns helpers in mptcp

by Geliang Tang

From: Geliang Tang <tanggeliang(a)kylinos.cn> New netns selftest helpers netns_new() and netns_free() has been added in network_helpers.c, let's use them in mptcp selftests too instead of using MPTCP's own helpers create_netns() and cleanup_netns(). Signed-off-by: Geliang Tang <tanggeliang(a)kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- v3: - No code has changed. - Change subject prefix as "bpf-next/net" since CI complains that this patch cannot be merged. - Add Matt's Reviewed-by tag. v2: - Use netns_new/netns_free instead of create_netns/cleanup_netns as Martin suggested. v1: selftests/bpf: Use make/remove netns helpers in mptcp --- .../testing/selftests/bpf/prog_tests/mptcp.c | 42 ++++++------------- 1 file changed, 12 insertions(+), 30 deletions(-) diff --git a/tools/testing/selftests/bpf/prog_tests/mptcp.c b/tools/testing/selftests/bpf/prog_tests/mptcp.c index be3cad2aff77..f8eb7f9d4fd2 100644 --- a/tools/testing/selftests/bpf/prog_tests/mptcp.c +++ b/tools/testing/selftests/bpf/prog_tests/mptcp.c @@ -69,24 +69,6 @@ struct mptcp_storage { char ca_name[TCP_CA_NAME_MAX]; }; -static struct nstoken *create_netns(void) -{ - SYS(fail, "ip netns add %s", NS_TEST); - SYS(fail, "ip -net %s link set dev lo up", NS_TEST); - - return open_netns(NS_TEST); -fail: - return NULL; -} - -static void cleanup_netns(struct nstoken *nstoken) -{ - if (nstoken) - close_netns(nstoken); - - SYS_NOFAIL("ip netns del %s", NS_TEST); -} - static int start_mptcp_server(int family, const char *addr_str, __u16 port, int timeout_ms) { @@ -206,15 +188,15 @@ static int run_test(int cgroup_fd, int server_fd, bool is_mptcp) static void test_base(void) { - struct nstoken *nstoken = NULL; + struct netns_obj *netns = NULL; int server_fd, cgroup_fd; cgroup_fd = test__join_cgroup("/mptcp"); if (!ASSERT_GE(cgroup_fd, 0, "test__join_cgroup")) return; - nstoken = create_netns(); - if (!ASSERT_OK_PTR(nstoken, "create_netns")) + netns = netns_new(NS_TEST, true); + if (!ASSERT_OK_PTR(netns, "netns_new")) goto fail; /* without MPTCP */ @@ -237,7 +219,7 @@ static void test_base(void) close(server_fd); fail: - cleanup_netns(nstoken); + netns_free(netns); close(cgroup_fd); } @@ -322,21 +304,21 @@ static int run_mptcpify(int cgroup_fd) static void test_mptcpify(void) { - struct nstoken *nstoken = NULL; + struct netns_obj *netns = NULL; int cgroup_fd; cgroup_fd = test__join_cgroup("/mptcpify"); if (!ASSERT_GE(cgroup_fd, 0, "test__join_cgroup")) return; - nstoken = create_netns(); - if (!ASSERT_OK_PTR(nstoken, "create_netns")) + netns = netns_new(NS_TEST, true); + if (!ASSERT_OK_PTR(netns, "netns_new")) goto fail; ASSERT_OK(run_mptcpify(cgroup_fd), "run_mptcpify"); fail: - cleanup_netns(nstoken); + netns_free(netns); close(cgroup_fd); } @@ -414,7 +396,7 @@ static void run_subflow(void) static void test_subflow(void) { struct mptcp_subflow *skel; - struct nstoken *nstoken; + struct netns_obj *netns; int cgroup_fd; cgroup_fd = test__join_cgroup("/mptcp_subflow"); @@ -437,8 +419,8 @@ static void test_subflow(void) if (!ASSERT_OK_PTR(skel->links._getsockopt_subflow, "attach _getsockopt_subflow")) goto skel_destroy; - nstoken = create_netns(); - if (!ASSERT_OK_PTR(nstoken, "create_netns: mptcp_subflow")) + netns = netns_new(NS_TEST, true); + if (!ASSERT_OK_PTR(netns, "netns_new: mptcp_subflow")) goto skel_destroy; if (endpoint_init("subflow") < 0) @@ -447,7 +429,7 @@ static void test_subflow(void) run_subflow(); close_netns: - cleanup_netns(nstoken); + netns_free(netns); skel_destroy: mptcp_subflow__destroy(skel); close_cgroup: -- 2.45.2

11 months, 1 week

2
1
0 0

[PATCH net-next v1 0/7] devmem TCP fixes

by Mina Almasry

A few unrelated devmem TCP fixes bundled in a series for some convenience (if that's ok). Patch 1-2: fix naming and provide page_pool_alloc_netmem for fragged netmem. Patch 3-4: fix issues with dma-buf dma addresses being potentially passed to dma_sync_for_* helpers. Patch 5-6: fix syzbot SO_DEVMEM_DONTNEED issue and add test for this case. Mina Almasry (6): net: page_pool: rename page_pool_alloc_netmem to *_netmems net: page_pool: create page_pool_alloc_netmem page_pool: disable sync for cpu for dmabuf memory provider netmem: add netmem_prefetch net: fix SO_DEVMEM_DONTNEED looping too long ncdevmem: add test for too many token_count Samiullah Khawaja (1): page_pool: Set `dma_sync` to false for devmem memory provider include/net/netmem.h | 7 ++++ include/net/page_pool/helpers.h | 50 ++++++++++++++++++-------- include/net/page_pool/types.h | 2 +- net/core/devmem.c | 9 +++-- net/core/page_pool.c | 11 +++--- net/core/sock.c | 46 ++++++++++++++---------- tools/testing/selftests/net/ncdevmem.c | 11 ++++++ 7 files changed, 93 insertions(+), 43 deletions(-) -- 2.47.0.163.g1226f6d8fa-goog

11 months, 1 week

3
12
0 0

[PATCH v5 0/2] selftests/resctrl: SNC kernel support discovery

by Maciej Wieczor-Retman

Changes v5: - Tests are skipped if snc_unreliable was set. - Moved resctrlfs.c changes from patch 2/2 to 1/2. - Removed CAT changes since it's not impacted by SNC in the selftest. - Updated various comments. - Fixed a bunch of minor issues pointed out in the review. Changes v4: - Printing SNC warnings at the start of every test. - Printing SNC warnings at the end of every relevant test. - Remove global snc_mode variable, consolidate snc detection functions into one. - Correct minor mistakes. Changes v3: - Reworked patch 2. - Changed minor things in patch 1 like function name and made corrections to the patch message. Changes v2: - Removed patches 2 and 3 since now this part will be supported by the kernel. Sub-Numa Clustering (SNC) allows splitting CPU cores, caches and memory into multiple NUMA nodes. When enabled, NUMA-aware applications can achieve better performance on bigger server platforms. SNC support in the kernel was merged into x86/cache [1]. With SNC enabled and kernel support in place all the tests will function normally (aside from effective cache size). There might be a problem when SNC is enabled but the system is still using an older kernel version without SNC support. Currently the only message displayed in that situation is a guess that SNC might be enabled and is causing issues. That message also is displayed whenever the test fails on an Intel platform. Add a mechanism to discover kernel support for SNC which will add more meaning and certainty to the error message. Add runtime SNC mode detection and verify how reliable that information is. Series was tested on Ice Lake server platforms with SNC disabled, SNC-2 and SNC-4. The tests were also ran with and without kernel support for SNC. Series applies cleanly on kselftest/next. [1] https://lore.kernel.org/all/20240628215619.76401-1-tony.luck@intel.com/ Previous versions of this series: [v1] https://lore.kernel.org/all/cover.1709721159.git.maciej.wieczor-retman@inte… [v2] https://lore.kernel.org/all/cover.1715769576.git.maciej.wieczor-retman@inte… [v3] https://lore.kernel.org/all/cover.1719842207.git.maciej.wieczor-retman@inte… [v4] https://lore.kernel.org/all/cover.1720774981.git.maciej.wieczor-retman@inte… Maciej Wieczor-Retman (2): selftests/resctrl: Adjust effective L3 cache size with SNC enabled selftests/resctrl: Adjust SNC support messages tools/testing/selftests/resctrl/cmt_test.c | 8 +- tools/testing/selftests/resctrl/mba_test.c | 8 +- tools/testing/selftests/resctrl/mbm_test.c | 10 +- tools/testing/selftests/resctrl/resctrl.h | 7 + .../testing/selftests/resctrl/resctrl_tests.c | 8 +- tools/testing/selftests/resctrl/resctrlfs.c | 132 ++++++++++++++++++ 6 files changed, 166 insertions(+), 7 deletions(-) -- 2.46.2

11 months, 1 week

2
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror