October 2025 - Linux-kselftest-mirror

[PATCH] selftests/tracing: Add basic test for trace_marker_raw file

by Steven Rostedt

From: Steven Rostedt <rostedt(a)goodmis.org> Commit 64cf7d058a00 ("tracing: Have trace_marker use per-cpu data to read user space") made an update that fixed both trace_marker and trace_marker_raw. But the small difference made to trace_marker_raw had a blatant bug in it that any basic testing would have uncovered. Unfortunately, the self tests have tests for trace_marker but nothing for trace_marker_raw which allowed the bug to get upstream. Add basic selftests to test trace_marker_raw so that this doesn't happen again. Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- .../ftrace/test.d/00basic/trace_marker_raw.tc | 107 ++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 tools/testing/selftests/ftrace/test.d/00basic/trace_marker_raw.tc diff --git a/tools/testing/selftests/ftrace/test.d/00basic/trace_marker_raw.tc b/tools/testing/selftests/ftrace/test.d/00basic/trace_marker_raw.tc new file mode 100644 index 000000000000..7daf7292209e --- /dev/null +++ b/tools/testing/selftests/ftrace/test.d/00basic/trace_marker_raw.tc @@ -0,0 +1,107 @@ +#!/bin/sh +# SPDX-License-Identifier: GPL-2.0 +# description: Basic tests on writing to trace_marker_raw +# requires: trace_marker_raw +# flags: instance + +is_little_endian() { + if lscpu | grep -q 'Little Endian'; then + echo 1; + else + echo 0; + fi +} + +little=`is_little_endian` + +make_str() { + id=$1 + cnt=$2 + + if [ $little -eq 1 ]; then + val=`printf "\\%03o\\%03o\\%03o\\%03o" \ + $(($id & 0xff)) \ + $((($id >> 8) & 0xff)) \ + $((($id >> 16) & 0xff)) \ + $((($id >> 24) & 0xff))` + else + val=`printf "\\%03o\\%03o\\%03o\\%03o" \ + $((($id >> 24) & 0xff)) \ + $((($id >> 16) & 0xff)) \ + $((($id >> 8) & 0xff)) \ + $(($id & 0xff))` + fi + + data=`printf -- 'X%.0s' $(seq $cnt)` + + printf "${val}${data}" +} + +write_buffer() { + id=$1 + size=$2 + + # write the string into the raw marker + make_str $id $size > trace_marker_raw +} + + +test_multiple_writes() { + + # Write a bunch of data where the id is the count of + # data to write + for i in `seq 1 10` `seq 101 110` `seq 1001 1010`; do + write_buffer $i $i + done + + # add a little buffer + echo stop > trace_marker + + # Check to make sure the number of entries is the id (rounded up by 4) + awk '/.*: # [0-9a-f]* / { + print; + cnt = -1; + for (i = 0; i < NF; i++) { + # The counter is after the "#" marker + if ( $i == "#" ) { + i++; + cnt = strtonum("0x" $i); + num = NF - (i + 1); + # The number of items is always rounded up by 4 + cnt2 = int((cnt + 3) / 4) * 4; + if (cnt2 != num) { + exit 1; + } + break; + } + } + } + // { if (NR > 30) { exit 0; } } ' trace_pipe; +} + + +get_buffer_data_size() { + sed -ne 's/^.*data.*size:$[0-9][0-9]*$.*/\1/p' events/header_page +} + +test_buffer() { + + # The id must be four bytes, test that 3 bytes fails a write + if echo -n abc > ./trace_marker_raw ; then + echo "Too small of write expected to fail but did not" + exit_fail + fi + + size=`get_buffer_data_size` + echo size = $size + + # Now add a little more than what it can handle + + if write_buffer 0xdeadbeef $size ; then + echo "Too big of write expected to fail but did not" + exit_fail + fi +} + +test_buffer +test_multiple_writes -- 2.51.0

1 month, 3 weeks

3
4
0 0

[PATCH v4 00/35] sparc64: vdso: Switch to the generic vDSO library

by Thomas Weißschuh

The generic vDSO provides a lot common functionality shared between different architectures. SPARC is the last architecture not using it, preventing some necessary code cleanup. Make use of the generic infrastructure. Follow-up to and replacement for Arnd's SPARC vDSO removal patches: https://lore.kernel.org/lkml/20250707144726.4008707-1-arnd@kernel.org/ SPARC64 can not map .bss into userspace, so the vDSO datapages are switched over to be allocated dynamically. This requires changes to the s390 and random subsystem vDSO initialization as preparation. The random subsystem changes in turn require some cleanup of the vDSO headers to not end up as ugly #ifdef mess. Tested on a Niagara T4 and QEMU. This has a semantic conflict with my series "vdso: Reject absolute relocations during build" [0]. The last patch of this series expects all users of the generic vDSO library to use the vdsocheck tool. This is not the case (yet) for SPARC64. I do have the patches for the integration, the specifics will depend on which series is applied first. Based on v6.18-rc1. [0] https://lore.kernel.org/lkml/20250812-vdso-absolute-reloc-v4-0-61a8b615e5ec… Signed-off-by: Thomas Weißschuh <thomas.weissschuh(a)linutronix.de> --- Changes in v4: - Rebase on v6.18-rc1. - Keep inclusion of asm/clocksource.h from linux/clocksource.h - Reword description of "s390/time: Set up vDSO datapage later" - Link to v3: https://lore.kernel.org/r/20250917-vdso-sparc64-generic-2-v3-0-3679b1bc8ee8… Changes in v3: - Allocate vDSO data pages dynamically (and lots of preparations for that) - Drop clock_getres() - Fix 32bit clock_gettime() syscall fallback - Link to v2: https://lore.kernel.org/r/20250815-vdso-sparc64-generic-2-v2-0-b5ff80672347… Changes in v2: - Rebase on v6.17-rc1 - Drop RFC state - Fix typo in commit message - Drop duplicate 'select GENERIC_TIME_VSYSCALL' - Merge "sparc64: time: Remove architecture-specific clocksource data" into the main conversion patch. It violated the check in __clocksource_register_scale() - Link to v1: https://lore.kernel.org/r/20250724-vdso-sparc64-generic-2-v1-0-e376a3bd24d1… --- Arnd Bergmann (1): clocksource: remove ARCH_CLOCKSOURCE_DATA Thomas Weißschuh (34): selftests: vDSO: vdso_test_correctness: Handle different tv_usec types arm64: vDSO: getrandom: Explicitly include asm/alternative.h arm64: vDSO: gettimeofday: Explicitly include vdso/clocksource.h arm64: vDSO: compat_gettimeofday: Add explicit includes ARM: vdso: gettimeofday: Add explicit includes powerpc/vdso/gettimeofday: Explicitly include vdso/time32.h powerpc/vdso: Explicitly include asm/cputable.h and asm/feature-fixups.h LoongArch: vDSO: Explicitly include asm/vdso/vdso.h MIPS: vdso: Add include guard to asm/vdso/vdso.h MIPS: vdso: Explicitly include asm/vdso/vdso.h random: vDSO: Add explicit includes vdso/gettimeofday: Add explicit includes vdso/helpers: Explicitly include vdso/processor.h vdso/datapage: Remove inclusion of gettimeofday.h vdso/datapage: Trim down unnecessary includes random: vDSO: trim vDSO includes random: vDSO: remove ifdeffery random: vDSO: split out datapage update into helper functions random: vDSO: only access vDSO datapage after random_init() s390/time: Set up vDSO datapage later vdso/datastore: Reduce scope of some variables in vvar_fault() vdso/datastore: Drop inclusion of linux/mmap_lock.h vdso/datastore: Map pages through struct page vdso/datastore: Allocate data pages dynamically sparc64: vdso: Link with -z noexecstack sparc64: vdso: Remove obsolete "fake section table" reservation sparc64: vdso: Replace code patching with runtime conditional sparc64: vdso: Move hardware counter read into header sparc64: vdso: Move syscall fallbacks into header sparc64: vdso: Introduce vdso/processor.h sparc64: vdso: Switch to the generic vDSO library sparc64: vdso2c: Drop sym_vvar_start handling sparc64: vdso2c: Remove symbol handling sparc64: vdso: Implement clock_gettime64() arch/arm/include/asm/vdso/gettimeofday.h | 2 + arch/arm64/include/asm/vdso/compat_gettimeofday.h | 3 + arch/arm64/include/asm/vdso/gettimeofday.h | 2 + arch/arm64/kernel/vdso/vgetrandom.c | 2 + arch/loongarch/kernel/process.c | 1 + arch/loongarch/kernel/vdso.c | 1 + arch/mips/include/asm/vdso/vdso.h | 5 + arch/mips/kernel/vdso.c | 1 + arch/powerpc/include/asm/vdso/gettimeofday.h | 1 + arch/powerpc/include/asm/vdso/processor.h | 3 + arch/s390/kernel/time.c | 4 +- arch/sparc/Kconfig | 3 +- arch/sparc/include/asm/clocksource.h | 9 - arch/sparc/include/asm/processor.h | 3 + arch/sparc/include/asm/processor_32.h | 2 - arch/sparc/include/asm/processor_64.h | 25 -- arch/sparc/include/asm/vdso.h | 2 - arch/sparc/include/asm/vdso/clocksource.h | 10 + arch/sparc/include/asm/vdso/gettimeofday.h | 184 ++++++++++ arch/sparc/include/asm/vdso/processor.h | 41 +++ arch/sparc/include/asm/vdso/vsyscall.h | 10 + arch/sparc/include/asm/vvar.h | 75 ---- arch/sparc/kernel/Makefile | 1 - arch/sparc/kernel/time_64.c | 6 +- arch/sparc/kernel/vdso.c | 69 ---- arch/sparc/vdso/Makefile | 8 +- arch/sparc/vdso/vclock_gettime.c | 380 ++------------------- arch/sparc/vdso/vdso-layout.lds.S | 26 +- arch/sparc/vdso/vdso.lds.S | 2 - arch/sparc/vdso/vdso2c.c | 24 -- arch/sparc/vdso/vdso2c.h | 45 +-- arch/sparc/vdso/vdso32/vdso32.lds.S | 4 +- arch/sparc/vdso/vma.c | 274 +-------------- drivers/char/random.c | 71 ++-- include/linux/clocksource.h | 6 +- include/linux/vdso_datastore.h | 6 + include/vdso/datapage.h | 23 +- include/vdso/helpers.h | 1 + init/main.c | 2 + kernel/time/Kconfig | 4 - lib/vdso/datastore.c | 73 ++-- lib/vdso/getrandom.c | 3 + lib/vdso/gettimeofday.c | 17 + .../testing/selftests/vDSO/vdso_test_correctness.c | 8 +- 44 files changed, 448 insertions(+), 994 deletions(-) --- base-commit: 28b1ac5ccd8d4900a8f53f0e6e84d517a7ccc71f change-id: 20250722-vdso-sparc64-generic-2-25f2e058e92c Best regards, -- Thomas Weißschuh <thomas.weissschuh(a)linutronix.de>

1 month, 3 weeks

8
54
0 0

[PATCH 0/3] introduce VM_MAYBE_GUARD and make it sticky

by Lorenzo Stoakes

Currently, guard regions are not visible to users except through /proc/$pid/pagemap, with no explicit visibility at the VMA level. This makes the feature less useful, as it isn't entirely apparent which VMAs may have these entries present, especially when performing actions which walk through memory regions such as those performed by CRIU. This series addresses this issue by introducing the VM_MAYBE_GUARD flag which fulfils this role, updating the smaps logic to display an entry for these. The semantics of this flag are that a guard region MAY be present if set (we cannot be sure, as we can't efficiently track whether an MADV_GUARD_REMOVE finally removes all the guard regions in a VMA) - but if not set the VMA definitely does NOT have any guard regions present. It's problematic to establish this flag without further action, because that means that VMAs with guard regions in them become non-mergeable with adjacent VMAs for no especially good reason. To work around this, this series also introduces the concept of 'sticky' VMA flags - that is flags which: a. if set in one VMA and not in another still permit those VMAs to be merged (if otherwise compatible). b. When they are merged, the resultant VMA must have the flag set. The VMA logic is updated to propagate these flags correctly. Additionally, VM_MAYBE_GUARD being an explicit VMA flag allows us to solve an issue with file-backed guard regions - previously these established an anon_vma object for file-backed mappings solely to have vma_needs_copy() correctly propagate guard region mappings to child processes. We introduce a new flag alias VM_COPY_ON_FORK (which currently only specifies VM_MAYBE_GUARD) and update vma_needs_copy() to check explicitly for this flag and to copy page tables if it is present, which resolves this issue. Finally we introduce extensive VMA userland tests to assert that the sticky VMA logic behaves correctly as well as guard region self tests to assert that smaps visibility is correctly implemented. Lorenzo Stoakes (3): mm: introduce VM_MAYBE_GUARD and make visible for guard regions mm: implement sticky, copy on fork VMA flags selftests/mm/guard-regions: add smaps visibility test Documentation/filesystems/proc.rst | 1 + fs/proc/task_mmu.c | 1 + include/linux/mm.h | 33 ++++++ include/trace/events/mmflags.h | 1 + mm/madvise.c | 22 ++-- mm/memory.c | 3 + mm/vma.c | 22 ++-- tools/testing/selftests/mm/guard-regions.c | 120 +++++++++++++++++++++ tools/testing/selftests/mm/vm_util.c | 5 + tools/testing/selftests/mm/vm_util.h | 1 + tools/testing/vma/vma.c | 89 +++++++++++++-- tools/testing/vma/vma_internal.h | 33 ++++++ 12 files changed, 303 insertions(+), 28 deletions(-) -- 2.51.0

1 month, 3 weeks

5
27
0 0

[PATCH net-next v2 0/5] psp: track stats from core and provide a driver stats api

by Daniel Zahka

This series introduces stats counters for psp. Device key rotations, and so called 'stale-events' are common to all drivers and are tracked by the core. A driver facing api is provided for reporting stats required by the "Implementation Requirements" section of the PSP Architecture Specification. Drivers must implement these stats. Lastly, implementations of the driver stats api for mlx5 and netdevsim are included. Here is the output of running the psp selftest suite and then printing out stats with the ynl cli on system with a psp-capable CX7: $ ./ksft-psp-stats/drivers/net/psp.py TAP version 13 1..28 ok 1 psp.test_case # SKIP Test requires IPv4 connectivity ok 2 psp.data_basic_send_v0_ip6 ok 3 psp.test_case # SKIP Test requires IPv4 connectivity ok 4 psp.data_basic_send_v1_ip6 ok 5 psp.test_case # SKIP Test requires IPv4 connectivity ok 6 psp.data_basic_send_v2_ip6 # SKIP ('PSP version not supported', 'hdr0-aes-gmac-128') ok 7 psp.test_case # SKIP Test requires IPv4 connectivity ok 8 psp.data_basic_send_v3_ip6 # SKIP ('PSP version not supported', 'hdr0-aes-gmac-256') ok 9 psp.test_case # SKIP Test requires IPv4 connectivity ok 10 psp.data_mss_adjust_ip6 ok 11 psp.dev_list_devices ok 12 psp.dev_get_device ok 13 psp.dev_get_device_bad ok 14 psp.dev_rotate ok 15 psp.dev_rotate_spi ok 16 psp.assoc_basic ok 17 psp.assoc_bad_dev ok 18 psp.assoc_sk_only_conn ok 19 psp.assoc_sk_only_mismatch ok 20 psp.assoc_sk_only_mismatch_tx ok 21 psp.assoc_sk_only_unconn ok 22 psp.assoc_version_mismatch ok 23 psp.assoc_twice ok 24 psp.data_send_bad_key ok 25 psp.data_send_disconnect ok 26 psp.data_stale_key ok 27 psp.removal_device_rx # XFAIL Test only works on netdevsim ok 28 psp.removal_device_bi # XFAIL Test only works on netdevsim # Totals: pass:19 fail:0 xfail:2 xpass:0 skip:7 error:0 # # Responder logs (0): # STDERR: # Set PSP enable on device 1 to 0x3 # Set PSP enable on device 1 to 0x0 $ cd ynl/ $ ./pyynl/cli.py --spec netlink/specs/psp.yaml --dump get-stats [{'dev-id': 1, 'key-rotations': 5, 'rx-auth-fail': 21, 'rx-bad': 0, 'rx-bytes': 11844, 'rx-error': 0, 'rx-packets': 94, 'stale-events': 6, 'tx-bytes': 1128456, 'tx-error': 0, 'tx-packets': 780}] CHANGES: v2: - don't return skb->len from psp_nl_get_stats_dumpit() on success and EMSGSIZE - use %pe to print PTR_ERR() v1: https://lore.kernel.org/netdev/20251022193739.1376320-1-daniel.zahka@gmail.… Daniel Zahka (2): selftests: drv-net: psp: add assertions on core-tracked psp dev stats netdevsim: implement psp device stats Jakub Kicinski (3): psp: report basic stats from the core psp: add stats from psp spec to driver facing api net/mlx5e: Add PSP stats support for Rx/Tx flows Documentation/netlink/specs/psp.yaml | 95 +++++++ .../mellanox/mlx5/core/en_accel/psp.c | 239 ++++++++++++++++-- .../mellanox/mlx5/core/en_accel/psp.h | 18 ++ .../mellanox/mlx5/core/en_accel/psp_rxtx.c | 1 + .../net/ethernet/mellanox/mlx5/core/en_main.c | 5 + drivers/net/netdevsim/netdevsim.h | 5 + drivers/net/netdevsim/psp.c | 27 ++ include/net/psp/types.h | 35 +++ include/uapi/linux/psp.h | 18 ++ net/psp/psp-nl-gen.c | 19 ++ net/psp/psp-nl-gen.h | 2 + net/psp/psp_main.c | 3 +- net/psp/psp_nl.c | 94 +++++++ net/psp/psp_sock.c | 4 +- tools/testing/selftests/drivers/net/psp.py | 13 + 15 files changed, 561 insertions(+), 17 deletions(-) -- 2.47.3

1 month, 3 weeks

4
10
0 0

[PATCH 0/8] Initial DMABUF support for iommufd

by Jason Gunthorpe

This series is the start of adding full DMABUF support to iommufd. Currently it is limited to only work with VFIO's DMABUF exporter. It sits on top of Leon's series to add a DMABUF exporter to VFIO: https://lore.kernel.org/all/cover.1760368250.git.leon@kernel.org/ The existing IOMMU_IOAS_MAP_FILE is enhanced to detect DMABUF fd's, but otherwise works the same as it does today for a memfd. The user can select a slice of the FD to map into the ioas and if the underliyng alignment requirements are met it will be placed in the iommu_domain. Though limited, it is enough to allow a VMM like QEMU to connect MMIO BAR memory from VFIO to an iommu_domain controlled by iommufd. This is used for PCI Peer to Peer support in VMs, and is the last feature that the VFIO type 1 container has that iommufd couldn't do. The VFIO type1 version extracts raw PFNs from VMAs, which has no lifetime control and is a use-after-free security problem. Instead iommufd relies on revokable DMABUFs. Whenever VFIO thinks there should be no access to the MMIO it can shoot down the mapping in iommufd which will unmap it from the iommu_domain. There is no automatic remap, this is a safety protocol so the kernel doesn't get stuck. Userspace is expected to know it is doing something that will revoke the dmabuf and map/unmap it around the activity. Eg when QEMU goes to issue FLR it should do the map/unmap to iommufd. Since DMABUF is missing some key general features for this use case it relies on a "private interconnect" between VFIO and iommufd via the vfio_pci_dma_buf_iommufd_map() call. The call confirms the DMABUF has revoke semantics and delivers a phys_addr for the memory suitable for use with iommu_map(). Medium term there is a desire to expand the supported DMABUFs to include GPU drivers to support DPDK/SPDK type use cases so future series will work to add a general concept of revoke and a general negotiation of interconnect to remove vfio_pci_dma_buf_iommufd_map(). I also plan another series to modify iommufd's vfio_compat to transparently pull a dmabuf out of a VFIO VMA to emulate more of the uAPI of type1. The latest series for interconnect negotation to exchange a phys_addr is: https://lore.kernel.org/r/20251027044712.1676175-1-vivek.kasireddy@intel.com And the discussion for design of revoke is here: https://lore.kernel.org/dri-devel/20250114173103.GE5556@nvidia.com/ This is on github: https://github.com/jgunthorpe/linux/commits/iommufd_dmabuf The branch has various modifications to Leon's series I've suggested. Jason Gunthorpe (8): iommufd: Add DMABUF to iopt_pages iommufd: Do not map/unmap revoked DMABUFs iommufd: Allow a DMABUF to be revoked iommufd: Allow MMIO pages in a batch iommufd: Have pfn_reader process DMABUF iopt_pages iommufd: Have iopt_map_file_pages convert the fd to a file iommufd: Accept a DMABUF through IOMMU_IOAS_MAP_FILE iommufd/selftest: Add some tests for the dmabuf flow drivers/iommu/iommufd/io_pagetable.c | 74 +++- drivers/iommu/iommufd/io_pagetable.h | 53 ++- drivers/iommu/iommufd/ioas.c | 8 +- drivers/iommu/iommufd/iommufd_private.h | 13 +- drivers/iommu/iommufd/iommufd_test.h | 10 + drivers/iommu/iommufd/main.c | 10 + drivers/iommu/iommufd/pages.c | 407 ++++++++++++++++-- drivers/iommu/iommufd/selftest.c | 142 ++++++ tools/testing/selftests/iommu/iommufd.c | 43 ++ tools/testing/selftests/iommu/iommufd_utils.h | 44 ++ 10 files changed, 741 insertions(+), 63 deletions(-) base-commit: fc882154e421f82677925d33577226e776bb07a4 -- 2.43.0

1 month, 3 weeks

3
11
0 0

[PATCH nf-next v8 0/3] Add IPIP flowtable SW acceleration

by Lorenzo Bianconi

Introduce SW acceleration for IPIP tunnels in the netfilter flowtable infrastructure. This series introduces basic infrastructure to accelerate other tunnel types (e.g. IP6IP6). --- Changes in v8: - Rebase on top of the following series (not yet applied) https://patchwork.ozlabs.org/project/netfilter-devel/list/?series=477081 - Link to v7: https://lore.kernel.org/r/20251021-nf-flowtable-ipip-v7-0-a45214896106@kern… Changes in v7: - Introduce sw acceleration for tx path of IPIP tunnels - Rely on exact match during flowtable entry lookup - Fix typos - Link to v6: https://lore.kernel.org/r/20250818-nf-flowtable-ipip-v6-0-eda90442739c@kern… Changes in v6: - Rebase on top of nf-next main branch - Link to v5: https://lore.kernel.org/r/20250721-nf-flowtable-ipip-v5-0-0865af9e58c6@kern… Changes in v5: - Rely on __ipv4_addr_hash() to compute the hash used as encap ID - Remove unnecessary pskb_may_pull() in nf_flow_tuple_encap() - Add nf_flow_ip4_ecanp_pop utility routine - Link to v4: https://lore.kernel.org/r/20250718-nf-flowtable-ipip-v4-0-f8bb1c18b986@kern… Changes in v4: - Use the hash value of the saddr, daddr and protocol of outer IP header as encapsulation id. - Link to v3: https://lore.kernel.org/r/20250703-nf-flowtable-ipip-v3-0-880afd319b9f@kern… Changes in v3: - Add outer IP header sanity checks - target nf-next tree instead of net-next - Link to v2: https://lore.kernel.org/r/20250627-nf-flowtable-ipip-v2-0-c713003ce75b@kern… Changes in v2: - Introduce IPIP flowtable selftest - Link to v1: https://lore.kernel.org/r/20250623-nf-flowtable-ipip-v1-1-2853596e3941@kern… --- Lorenzo Bianconi (3): net: netfilter: Add IPIP flowtable rx sw acceleration net: netfilter: Add IPIP flowtable tx sw acceleration selftests: netfilter: nft_flowtable.sh: Add IPIP flowtable selftest include/linux/netdevice.h | 16 +++ include/net/netfilter/nf_flow_table.h | 22 ++++ net/ipv4/ipip.c | 29 +++++ net/netfilter/nf_flow_table_core.c | 3 + net/netfilter/nf_flow_table_ip.c | 117 ++++++++++++++++++++- net/netfilter/nf_flow_table_path.c | 86 +++++++++++++-- .../selftests/net/netfilter/nft_flowtable.sh | 40 +++++++ 7 files changed, 298 insertions(+), 15 deletions(-) --- base-commit: 32e4b1bf1bbfe63e52e2fff7ade0aaeb805defe3 change-id: 20250623-nf-flowtable-ipip-1b3d7b08d067 Best regards, -- Lorenzo Bianconi <lorenzo(a)kernel.org>

1 month, 3 weeks

3
7
0 0

[PATCH net] selftests: netdevsim: Fix ethtool-features.sh fail

by Wang Liang

The test 'ethtool-features.sh' failed with the below output: TAP version 13 1..1 # timeout set to 600 # selftests: drivers/net/netdevsim: ethtool-features.sh # Warning: file ethtool-features.sh is not executable # ethtool: bad command line argument(s) # For more information run ethtool -h # ethtool: bad command line argument(s) # For more information run ethtool -h # ethtool: bad command line argument(s) # For more information run ethtool -h # ethtool: bad command line argument(s) # For more information run ethtool -h # ethtool: bad command line argument(s) # For more information run ethtool -h # ethtool: bad command line argument(s) # For more information run ethtool -h # ethtool: bad command line argument(s) # For more information run ethtool -h # ethtool: bad command line argument(s) # For more information run ethtool -h # ethtool: bad command line argument(s) # For more information run ethtool -h # ethtool: bad command line argument(s) # For more information run ethtool -h # FAILED 10/10 checks not ok 1 selftests: drivers/net/netdevsim: ethtool-features.sh # exit=1 Similar to commit 18378b0e49d9 ("selftests/damon: Add executable permission to test scripts"), the script 'ethtool-features.sh' has no executable permission, which leads to the warning 'file ethtool-features.sh is not executable'. Old version ethtool (my ethtool version is 5.16) does not support command 'ethtool --json -k enp1s0', which leads to the output 'ethtool: bad command line argument(s)'. This patch adds executable permission to script 'ethtool-features.sh', and check 'ethtool --json -k' support. After this patch: TAP version 13 1..1 # timeout set to 600 # selftests: drivers/net/netdevsim: ethtool-features.sh # SKIP: No --json -k support in ethtool ok 1 selftests: drivers/net/netdevsim: ethtool-features.sh Fixes: 0189270117c3 ("selftests: netdevsim: add a test checking ethtool features") Signed-off-by: Wang Liang <wangliang74(a)huawei.com> --- .../selftests/drivers/net/netdevsim/ethtool-features.sh | 5 +++++ 1 file changed, 5 insertions(+) mode change 100644 => 100755 tools/testing/selftests/drivers/net/netdevsim/ethtool-features.sh diff --git a/tools/testing/selftests/drivers/net/netdevsim/ethtool-features.sh b/tools/testing/selftests/drivers/net/netdevsim/ethtool-features.sh old mode 100644 new mode 100755 index bc210dc6ad2d..f771dc6839ea --- a/tools/testing/selftests/drivers/net/netdevsim/ethtool-features.sh +++ b/tools/testing/selftests/drivers/net/netdevsim/ethtool-features.sh @@ -7,6 +7,11 @@ NSIM_NETDEV=$(make_netdev) set -o pipefail +if ! ethtool --json -k $NSIM_NETDEV > /dev/null 2>&1; then + echo "SKIP: No --json -k support in ethtool" + exit $ksft_skip +fi + FEATS=" tx-checksum-ip-generic tx-scatter-gather -- 2.34.1

1 month, 3 weeks

4
11
0 0

[PATCH v4 0/5] mm: Refactor and improve VMA count limit code

by Kalesh Singh

Hi all, This series refactors the VMA count limit code to improve clarity, test coverage, and observability. The VMA count limit, controlled by sysctl_max_map_count, is a safeguard that prevents a single process from consuming excessive kernel memory by creating too many memory mappings. A major change since v3 is the first patch in the series which instead of attempting to fix overshooting the limit now documents that this is the intended behavior. As Hugh pointed out, the lenient check (>) in do_mmap() and do_brk_flags() is intentional to allow for potential VMA merges or expansions when the process is at the sysctl_max_map_count limit. The consensus is that this historical behavior is correct but non-obvious. This series now focuses on making that behavior clear and the surrounding code more robust. Based on feedback from Lorenzo and David, this series retains the helper function and the rename of map_count. The refined v4 series is now structured as follows: 1. Documents the lenient VMA count checks with comments to clarify their purpose. 2. Adds a comprehensive selftest to codify the expected behavior at the limit, including the lenient mmap case. 3. Introduces max_vma_count() to abstract the max map count sysctl, making the sysctl static and converting all callers to use the new helper. 4. Renames mm_struct->map_count to the more explicit vma_count for better code clarity. 5. Adds a tracepoint for observability when a process fails to allocate a VMA due to the count limit. Tested on x86_64 and arm64: 1. Build test: allyesconfig for rename 2. Selftests: cd tools/testing/selftests/mm && \ make && \ ./run_vmtests.sh -t max_vma_count 3. vma tests: cd tools/testing/vma && \ make && \ ./vma Link to v3: https://lore.kernel.org/r/20251013235259.589015-1-kaleshsingh@google.com/ Thanks to everyone for the valuable discussion on previous revisions. -- Kalesh Kalesh Singh (5): mm: Document lenient map_count checks mm/selftests: add max_vma_count tests mm: Introduce max_vma_count() to abstract the max map count sysctl mm: rename mm_struct::map_count to vma_count mm/tracing: introduce trace_mm_insufficient_vma_slots event MAINTAINERS | 2 + fs/binfmt_elf.c | 2 +- fs/coredump.c | 2 +- include/linux/mm.h | 2 - include/linux/mm_types.h | 2 +- include/trace/events/vma.h | 32 + kernel/fork.c | 2 +- mm/debug.c | 2 +- mm/internal.h | 3 + mm/mmap.c | 25 +- mm/mremap.c | 13 +- mm/nommu.c | 8 +- mm/util.c | 1 - mm/vma.c | 42 +- mm/vma_internal.h | 2 + tools/testing/selftests/mm/.gitignore | 1 + tools/testing/selftests/mm/Makefile | 1 + .../selftests/mm/max_vma_count_tests.c | 716 ++++++++++++++++++ tools/testing/selftests/mm/run_vmtests.sh | 5 + tools/testing/vma/vma.c | 32 +- tools/testing/vma/vma_internal.h | 13 +- 21 files changed, 856 insertions(+), 52 deletions(-) create mode 100644 include/trace/events/vma.h create mode 100644 tools/testing/selftests/mm/max_vma_count_tests.c base-commit: b227c04932039bccc21a0a89cd6df50fa57e4716 -- 2.51.1.851.g4ebd6896fd-goog

1 month, 3 weeks

2
8
0 0

[PATCH bpf-next 0/3] selftests/bpf: small improvements on tc_tunnel

by Alexis Lothoré (eBPF Foundation)

Hello, this series is a small follow-up to the test_tc_tunnel recent integration, to address some small missing details raised during the final review ([1]). This is mostly about adding some missing checks on net namespaces management. [1] https://lore.kernel.org/bpf/1ac9d14e-4250-480c-b863-410be78ac6c6@linux.dev/ Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore(a)bootlin.com> --- Alexis Lothoré (eBPF Foundation) (3): selftests/bpf: skip tc_tunnel subtest if its setup fails selftests/bpf: add checks in tc_tunnel when entering net namespaces selftests/bpf: use start_server_str rather than start_reuseport_server in tc_tunnel .../selftests/bpf/prog_tests/test_tc_tunnel.c | 162 ++++++++++++++------- 1 file changed, 107 insertions(+), 55 deletions(-) --- base-commit: 1e2d874b04ba46a3b9fe6697097aa437641f4339 change-id: 20251030-tc_tunnel_improv-6b9d1c22c6f6 Best regards, -- Alexis Lothoré, Bootlin Embedded Linux and Kernel engineering https://bootlin.com

1 month, 3 weeks

3
5
0 0

[PATCH net v3 0/3] mptcp: Fix conflicts between MPTCP and sockmap

by Jiayuan Chen

Overall, we encountered a warning [1] that can be triggered by running the selftest I provided. MPTCP creates subflows for data transmission between two endpoints. However, BPF can use sockops to perform additional operations when TCP completes the three-way handshake. The issue arose because we used sockmap in sockops, which replaces sk->sk_prot and some handlers. Since subflows also have their own specialized handlers, this creates a conflict and leads to traffic failure. Therefore, we need to reject operations targeting subflows. This patchset simply prevents the combination of subflows and sockmap without changing any functionality. A complete integration of MPTCP and sockmap would require more effort, for example, we would need to retrieve the parent socket from subflows in sockmap and implement handlers like read_skb. If maintainers don't object, we can further improve this in subsequent work. [1] truncated warning: [ 18.234652] ------------[ cut here ]------------ [ 18.234664] WARNING: CPU: 1 PID: 388 at net/mptcp/protocol.c:68 mptcp_stream_accept+0x34c/0x380 [ 18.234726] Modules linked in: [ 18.234755] RIP: 0010:mptcp_stream_accept+0x34c/0x380 [ 18.234762] RSP: 0018:ffffc90000cf3cf8 EFLAGS: 00010202 [ 18.234800] PKRU: 55555554 [ 18.234806] Call Trace: [ 18.234810] <TASK> [ 18.234837] do_accept+0xeb/0x190 [ 18.234861] ? __x64_sys_pselect6+0x61/0x80 [ 18.234898] ? _raw_spin_unlock+0x12/0x30 [ 18.234915] ? alloc_fd+0x11e/0x190 [ 18.234925] __sys_accept4+0x8c/0x100 [ 18.234930] __x64_sys_accept+0x1f/0x30 [ 18.234933] x64_sys_call+0x202f/0x20f0 [ 18.234966] do_syscall_64+0x72/0x9a0 [ 18.234979] ? switch_fpu_return+0x60/0xf0 [ 18.234993] ? irqentry_exit_to_user_mode+0xdb/0x1e0 [ 18.235002] ? irqentry_exit+0x3f/0x50 [ 18.235005] ? clear_bhb_loop+0x50/0xa0 [ 18.235022] ? clear_bhb_loop+0x50/0xa0 [ 18.235025] ? clear_bhb_loop+0x50/0xa0 [ 18.235028] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 18.235066] </TASK> [ 18.235109] ---[ end trace 0000000000000000 ]--- --- v2: https://lore.kernel.org/bpf/20251020060503.325369-1-jiayuan.chen@linux.dev/… Some advice suggested by Jakub Sitnicki v1: https://lore.kernel.org/mptcp/a0a2b87119a06c5ffaa51427a0964a05534fe6f1@linu… Some advice from Matthieu Baerts. Jiayuan Chen (3): net,mptcp: fix proto fallback detection with BPF sockmap bpf,sockmap: disallow MPTCP sockets from sockmap selftests/bpf: Add mptcp test with sockmap net/core/sock_map.c | 27 ++++ net/mptcp/protocol.c | 9 +- .../testing/selftests/bpf/prog_tests/mptcp.c | 150 ++++++++++++++++++ .../selftests/bpf/progs/mptcp_sockmap.c | 43 +++++ 4 files changed, 227 insertions(+), 2 deletions(-) create mode 100644 tools/testing/selftests/bpf/progs/mptcp_sockmap.c -- 2.43.0

1 month, 3 weeks

3
16
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror October 2025