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

[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

2 weeks, 3 days

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

2 weeks, 4 days

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

2 weeks, 4 days

3
16
0 0

[PATCH] selftests/timers: Skip some posix_timers tests on kernels < 6.13

by Wake Liu

Several tests in the posix_timers selftest fail on kernels older than 6.13. These tests check for timer behavior related to SIG_IGN, which was refactored in the 6.13 kernel cycle, notably by commit caf77435dd8a ("signal: Handle ignored signals in do_sigaction(action != SIG_IGN)"). To ensure the selftests pass on older, stable kernels, gate the affected tests with a ksft_min_kernel_version(6, 13) check. Signed-off-by: Wake Liu <wakel(a)google.com> --- tools/testing/selftests/timers/posix_timers.c | 21 +++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/tools/testing/selftests/timers/posix_timers.c b/tools/testing/selftests/timers/posix_timers.c index f0eceb0faf34..f228e51f8b58 100644 --- a/tools/testing/selftests/timers/posix_timers.c +++ b/tools/testing/selftests/timers/posix_timers.c @@ -256,6 +256,11 @@ static void *ignore_thread(void *arg) static void check_sig_ign(int thread) { + if (!ksft_min_kernel_version(6, 13)) { + // see caf77435dd8a + ksft_test_result_skip("Depends on refactor of posix timers in 6.13\n"); + return; + } struct tmrsig tsig = { }; struct itimerspec its; unsigned int tid = 0; @@ -342,6 +347,10 @@ static void check_sig_ign(int thread) static void check_rearm(void) { + if (!ksft_min_kernel_version(6, 13)) { + ksft_test_result_skip("Depends on refactor of posix timers in 6.13\n"); + return; + } struct tmrsig tsig = { }; struct itimerspec its; struct sigaction sa; @@ -398,6 +407,10 @@ static void check_rearm(void) static void check_delete(void) { + if (!ksft_min_kernel_version(6, 13)) { + ksft_test_result_skip("Depends on refactor of posix timers in 6.13\n"); + return; + } struct tmrsig tsig = { }; struct itimerspec its; struct sigaction sa; @@ -455,6 +468,10 @@ static inline int64_t calcdiff_ns(struct timespec t1, struct timespec t2) static void check_sigev_none(int which, const char *name) { + if (!ksft_min_kernel_version(6, 13)) { + ksft_test_result_skip("Depends on refactor of posix timers in 6.13\n"); + return; + } struct timespec start, now; struct itimerspec its; struct sigevent sev; @@ -493,6 +510,10 @@ static void check_sigev_none(int which, const char *name) static void check_gettime(int which, const char *name) { + if (!ksft_min_kernel_version(6, 13)) { + ksft_test_result_skip("Depends on refactor of posix timers in 6.13\n"); + return; + } struct itimerspec its, prev; struct timespec start, now; struct sigevent sev; -- 2.50.1.703.g449372360f-goog

2 weeks, 4 days

2
2
0 0

[PATCH bpf-next 0/4] selftests/bpf: convert test_tc_edt.sh into test_progs

by Alexis Lothoré (eBPF Foundation)

Hello, this is yet another conversion series, this time tackling the test_tc_edt.sh. This one was at the bottom of our list due to the fact that it is based on some bandwith measurement (and so, increasing the risk to make it flaky in CI), but here is an attempt anyway, as it also showcases a nice example of BPF-based rate shaping. The converted test roughly follows the original script logic, with two veths in two namespaces, a TCP connection between a client and a server, and the client pushing as much data as possible during a specific period. We then compute the effective data rate, shaped by the eBPF program, by reading the RX interface stats, and compare it to the target rate. The test passes if the measured rate is within a defined error margin. There are two knobs driving the robustness of the test in CI: - the test duration (the higher, the more precise is the effective rate) - the tolerated error margin The original test was configured with a 20s duration and a 1% error margin. The new test is configured with a 2s duration and a 2% error margin, to: - make the duration tolerable in CI - while keeping enough margin for rate measure fluctuations depending on the CI machines load This has been run multiple times locally to ensure that those values are sane, and once in CI before sending the series, but I suggest to let it live a few days in CI to see how it really behaves. Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore(a)bootlin.com> --- Alexis Lothoré (eBPF Foundation) (4): selftests/bpf: rename test_tc_edt.bpf.c section to expose program type selftests/bpf: integrate test_tc_edt into test_progs selftests/bpf: remove test_tc_edt.sh selftests/bpf: do not hardcode target rate in test_tc_edt BPF program tools/testing/selftests/bpf/Makefile | 2 - .../testing/selftests/bpf/prog_tests/test_tc_edt.c | 274 +++++++++++++++++++++ tools/testing/selftests/bpf/progs/test_tc_edt.c | 9 +- tools/testing/selftests/bpf/test_tc_edt.sh | 100 -------- 4 files changed, 279 insertions(+), 106 deletions(-) --- base-commit: 1e2d874b04ba46a3b9fe6697097aa437641f4339 change-id: 20251030-tc_edt-3ea8e8d3d14e Best regards, -- Alexis Lothoré, Bootlin Embedded Linux and Kernel engineering https://bootlin.com

2 weeks, 4 days

4
7
0 0

[PATCH bpf-next v3 0/2] bpf: Skip bounds adjustment for conditional jumps on same scalar register

by KaFai Wan

This small patchset is about avoid verifier bug warning when conditional jumps on same register when the register holds a scalar with range. v3: - Enhance is_scalar_branch_taken() to handle scalar case. (Eduard) - Update the selftest to cover all conditional jump opcodes. (Eduard) v2: https://lore.kernel.org/bpf/20251025053017.2308823-1-kafai.wan@linux.dev/ - Enhance is_branch_taken() and is_scalar_branch_taken() to handle branch direction computation for same register. (Eduard and Alexei) - Update the selftest. v1: https://lore.kernel.org/bpf/20251022164457.1203756-1-kafai.wan@linux.dev/ --- KaFai Wan (2): bpf: Skip bounds adjustment for conditional jumps on same scalar register selftests/bpf: Add test for conditional jumps on same scalar register kernel/bpf/verifier.c | 33 ++++ .../selftests/bpf/progs/verifier_bounds.c | 154 ++++++++++++++++++ 2 files changed, 187 insertions(+) -- 2.43.0

2 weeks, 4 days

2
4
0 0

[PATCH 00/12] tools/nolibc: always use 64-bit ino_t, off_t and time-related types

by Thomas Weißschuh

nolibc currently uses 32-bit types for various APIs. These are problematic as their reduced value range can lead to truncated values. Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> --- Thomas Weißschuh (12): tools/nolibc: use 64-bit ino_t tools/nolibc: handle 64-bit off_t for llseek tools/nolibc: prefer the llseek syscall tools/nolibc: use 64-bit off_t tools/nolibc: remove now superfluous overflow check in llseek tools/nolibc: remove more __nolibc_enosys() fallbacks tools/nolibc: prefer explicit 64-bit time-related system calls tools/nolibc: gettimeofday(): avoid libgcc 64-bit divisions tools/nolibc: use a custom struct timespec tools/nolibc: always use 64-bit time types selftests/nolibc: test compatibility of timespec and __kernel_timespec tools/nolibc: remove time conversions tools/include/nolibc/arch-s390.h | 3 + tools/include/nolibc/poll.h | 12 ++-- tools/include/nolibc/std.h | 6 +- tools/include/nolibc/sys.h | 21 +++--- tools/include/nolibc/sys/time.h | 2 +- tools/include/nolibc/sys/timerfd.h | 20 +----- tools/include/nolibc/time.h | 96 ++++++---------------------- tools/include/nolibc/types.h | 9 ++- tools/testing/selftests/nolibc/nolibc-test.c | 18 ++++++ 9 files changed, 68 insertions(+), 119 deletions(-) --- base-commit: 90ee85c0e1e4b5804ceebbd731653e10ef3849a6 change-id: 20251001-nolibc-uapi-types-1c072d10fcc7 Best regards, -- Thomas Weißschuh <linux(a)weissschuh.net>

2 weeks, 5 days

3
26
0 0

NEW PO 83199 Saturday, November 1, 2025 at 08:22:32 PM

by Procurement 05471

Hi Linux-kselftest, Please provide a quote for your products: Include: 1.Pricing (per unit) 2.Delivery cost & timeline 3.Quote expiry date Deadline: October Thanks! Danny Peddinti PathnSitu Trading

2 weeks, 6 days

1
0
0 0

[PATCH v2 0/2] Print map ID on successful creation

by Harshit Mogalapalli

Hi all, I have tried looking at an issue from the bpftool repository: https://github.com/libbpf/bpftool/issues/121 and this RFC tries to add that enhancement. Summary: Currently when a map creation is successful there is no message on the terminal, printing IDs on successful creation of maps can help notify the user and can be used in CI/CD. The first patch adds the logic for printing and the second patch adds a simple selftest for the same. The github issue is not fully solved with these two patches, as there are other bpf objects that might need similar additions. Would appreciate any inputs on this. Thank you very much. V1 --> V2: PATCH 1 updated [Thanks Yonghong for suggesting better way of error handling with a new label for close(fd); instead of calling multiple times] Regards, Harshit Harshit Mogalapalli (2): bpftool: Print map ID upon creation and support JSON output selftests/bpf: Add test for bpftool map ID printing tools/bpf/bpftool/map.c | 21 ++++++++--- .../testing/selftests/bpf/test_bpftool_map.sh | 36 +++++++++++++++++++ 2 files changed, 53 insertions(+), 4 deletions(-) -- 2.50.1

2 weeks, 6 days

3
8
0 0

[PATCH 00/22] mm/damon/tests: fix memory bugs in kunit tests

by SeongJae Park

DAMON kunit tests were initially written assuming those will be run on environments that are well controlled and therefore tolerant to transient test failures and bugs in the test code itself. The user-mode linux based manual run of the tests is one example of such an environment. And the test code was written for adding more test coverage as fast as possible, over making those safe and reliable. As a result, the tests resulted in having a number of bugs including real memory leaks, theoretical unhandled memory allocation failures, and unused memory allocations. The allocation failures that are not handled well are unlikely in the real world, since those allocations are too small to fail. But in theory, it can happen and cause inappropriate memory access. It is arguable if bugs in test code can really harm users. But, anyway bugs are bugs that need to be fixed. Fix the bugs one by one. Also Cc stable@ for the fixes of memory leak and unhandled memory allocation failures. The unused memory allocations are only a matter of memory efficiency, so not Cc-ing stable@. The first patch fixes memory leaks in the test code for the DAMON core layer. Following fifteen, three, and one patches respectively fix unhandled memory allocation failures in the test code for DAMON core layer, virtual address space DAMON operation set, and DAMON sysfs interface, one by one per test function. Final two patches remove memory allocations that are correctly deallocated at the end, but not really being used by any code. SeongJae Park (22): mm/damon/tests/core-kunit: fix memory leak in damon_test_set_filters_default_reject() mm/damon/tests/core-kunit: handle allocation failures in damon_test_regions() mm/damon/tests/core-kunit: handle memory failure from damon_test_target() mm/damon/tests/core-kunit: handle memory alloc failure from damon_test_aggregate() mm/damon/tests/core-kunit: handle alloc failures on damon_test_split_at() mm/damon/tests/core-kunit: handle alloc failures on damon_test_merge_two() mm/damon/tests/core-kunit: handle alloc failures on dasmon_test_merge_regions_of() mm/damon/tests/core-kunit: handle alloc failures on damon_test_split_regions_of() mm/damon/tests/core-kunit: handle alloc failures in damon_test_ops_registration() mm/damon/tests/core-kunit: handle alloc failures in damon_test_set_regions() mm/damon/tests/core-kunit: handle alloc failures in damon_test_update_monitoring_result() mm/damon/tests/core-kunit: handle alloc failure on damon_test_set_attrs() mm/damon/tests/core-kunit: handle alloc failres in damon_test_new_filter() mm/damon/tests/core-kunit: handle alloc failure on damos_test_commit_filter() mm/damon/tests/core-kunit: handle alloc failures on damos_test_filter_out() mm/damon/tests/core-kunit: handle alloc failures on damon_test_set_filters_default_reject() mm/damon/tests/vaddr-kunit: handle alloc failures on damon_do_test_apply_three_regions() mm/damon/tests/vaddr-kunit: handle alloc failures in damon_test_split_evenly_fail() mm/damon/tests/vaddr-kunit: handle alloc failures on damon_test_split_evenly_succ() mm/damon/tests/sysfs-kunit: handle alloc failures on damon_sysfs_test_add_targets() mm/damon/tests/core-kunit: remove unnecessary damon_ctx variable on damon_test_split_at() mm/damon/tests/core-kunit: remove unused ctx in damon_test_split_regions_of() mm/damon/tests/core-kunit.h | 125 ++++++++++++++++++++++++++++++++--- mm/damon/tests/sysfs-kunit.h | 25 +++++++ mm/damon/tests/vaddr-kunit.h | 26 +++++++- 3 files changed, 163 insertions(+), 13 deletions(-) base-commit: 75f0c76bb8c01fdea838a601dc3326b11177c0d8 -- 2.47.3

2 weeks, 6 days

1
22
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror