January 2025 - Linux-kselftest-mirror

selftests: core: unshare_test: WARNING: at mm/util.c:671 __kvmalloc_node_noprof

by Naresh Kamboju

The following kernel warning is noticed on all arch and all devices while running selftests: core: unshare_test on Linux next-20240823 and next-20240826. First seen on next-20240823. Good: next-20240822 BAD: next-20240823 and next-20240826 Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> Crash log: -------- # selftests: core: unshare_test <4>[ 61.084149] ------------[ cut here ]------------ <4>[ 61.085175] WARNING: CPU: 0 PID: 477 at mm/util.c:671 __kvmalloc_node_noprof (mm/util.c:671 (discriminator 1)) <4>[ 61.088958] Modules linked in: crct10dif_ce sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 drm fuse backlight dm_mod ip_tables x_tables <4>[ 61.093141] CPU: 0 UID: 0 PID: 477 Comm: unshare_test Not tainted 6.11.0-rc5-next-20240826 #1 <4>[ 61.094558] Hardware name: linux,dummy-virt (DT) <4>[ 61.096763] pstate: 23400009 (nzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) <4>[ 61.097841] pc : __kvmalloc_node_noprof (mm/util.c:671 (discriminator 1)) <4>[ 61.099701] lr : __kvmalloc_node_noprof (mm/util.c:661) <4>[ 61.100448] sp : ffff800080abbce0 <4>[ 61.100819] x29: ffff800080abbcf0 x28: fff0000004549280 x27: 0000000000000000 <4>[ 61.101744] x26: 0000000000000000 x25: 0000000000000000 x24: fff0000003615e40 <4>[ 61.102512] x23: fff0000003615ec0 x22: bfafa45863b285c8 x21: 0000000200002000 <4>[ 61.103232] x20: 00000000ffffffff x19: 0000000000400cc0 x18: 0000000000000000 <4>[ 61.104053] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 <4>[ 61.104927] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 <4>[ 61.105752] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 <4>[ 61.106606] x8 : 0000000000000001 x7 : 0000000000000001 x6 : 0000000000000005 <4>[ 61.107377] x5 : 0000000000000000 x4 : fff0000004549280 x3 : 0000000000000000 <4>[ 61.108207] x2 : 0000000000000000 x1 : 000000007fffffff x0 : 0000000000000000 <4>[ 61.109262] Call trace: <4>[ 61.109619] __kvmalloc_node_noprof (mm/util.c:671 (discriminator 1)) <4>[ 61.110248] alloc_fdtable (fs/file.c:133) <4>[ 61.110751] expand_files (include/linux/atomic/atomic-arch-fallback.h:457 include/linux/atomic/atomic-instrumented.h:33 fs/file.c:177 fs/file.c:238) <4>[ 61.111171] ksys_dup3 (fs/file.c:1337) <4>[ 61.111596] __arm64_sys_dup3 (fs/file.c:1355) <4>[ 61.112006] invoke_syscall (arch/arm64/include/asm/current.h:19 arch/arm64/kernel/syscall.c:54) <4>[ 61.112480] el0_svc_common.constprop.0 (include/linux/thread_info.h:127 (discriminator 2) arch/arm64/kernel/syscall.c:140 (discriminator 2)) <4>[ 61.112955] do_el0_svc (arch/arm64/kernel/syscall.c:152) <4>[ 61.113384] el0_svc (arch/arm64/include/asm/irqflags.h:55 arch/arm64/include/asm/irqflags.h:76 arch/arm64/kernel/entry-common.c:165 arch/arm64/kernel/entry-common.c:178 arch/arm64/kernel/entry-common.c:713) <4>[ 61.113742] el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:731) <4>[ 61.115181] el0t_64_sync (arch/arm64/kernel/entry.S:598) <4>[ 61.115709] ---[ end trace 0000000000000000 ]--- Crash Log links, -------- - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20240826/te… Crash failed comparison: ---------- - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20240826/te… metadata: ---- git describe: next-20240823 and next-20240826 git repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next git sha: c79c85875f1af04040fe4492ed94ce37ad729c4d kernel config: https://storage.tuxsuite.com/public/linaro/lkft/builds/2l2pZRzhgRkPgXIKLJCI… artifact location: https://storage.tuxsuite.com/public/linaro/lkft/builds/2l2pZRzhgRkPgXIKLJCI… build url: https://storage.tuxsuite.com/public/linaro/lkft/builds/2l2pZRzhgRkPgXIKLJCI… toolchain: clang-18 and gcc-13 Steps to reproduce: --------- - https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2l2paZVYTl… - https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2l2paZVYTl… Please let me know if you need more information. -- Linaro LKFT https://lkft.linaro.org

7 months, 4 weeks

2
2
0 0

[PATCH net-next v2 0/2] ipvlan: Support bonding events

by Etienne Champetier

No changes for first commit. Second commit rework bond_macvlan.sh test to add minimal ipvlan over bond testing (asked by Jakub during v1 review). Etienne Champetier (2): ipvlan: Support bonding events selftests: bonding: add ipvlan over bond testing drivers/net/ipvlan/ipvlan_main.c | 6 ++ .../selftests/drivers/net/bonding/Makefile | 2 +- .../drivers/net/bonding/bond_macvlan.sh | 99 ------------------- .../net/bonding/bond_macvlan_ipvlan.sh | 96 ++++++++++++++++++ .../selftests/drivers/net/bonding/config | 1 + 5 files changed, 104 insertions(+), 100 deletions(-) delete mode 100755 tools/testing/selftests/drivers/net/bonding/bond_macvlan.sh create mode 100755 tools/testing/selftests/drivers/net/bonding/bond_macvlan_ipvlan.sh -- 2.47.1

7 months, 4 weeks

2
3
0 0

[PATCH bpf-next v2 0/3] selftests: bpf: Migrate test_xdp_redirect.sh to test_progs

by Bastien Curutchet (eBPF Foundation)

Hi all, This patch series continues the work to migrate the *.sh tests into prog_tests. test_xdp_redirect.sh tests the XDP redirections done through bpf_redirect(). These XDP redirections are already tested by prog_tests/xdp_do_redirect.c but IMO it doesn't cover the exact same code path because xdp_do_redirect.c uses bpf_prog_test_run_opts() to trigger redirections of 'fake packets' while test_xdp_redirect.sh redirects packets coming from the network. Also, the test_xdp_redirect.sh script tests the redirections with both SKB and DRV modes while xdp_do_redirect.c only tests the DRV mode. The patch series adds two new test cases in prog_tests/xdp_do_redirect.c to replace the test_xdp_redirect.sh script. Signed-off-by: Bastien Curutchet (eBPF Foundation) <bastien.curutchet(a)bootlin.com> --- Changes in v2: - Use directly skel->progs instead of 'bpf_object__find_program_by_name()' - Use 'ip -n NSX' in SYS calls instead of opening NSX with open_netns() - Use #define for static indexes of veth1 and veth2 - Delete the useless second ping - Set nstoken to NULL after close_netns() - Merge the two added tests into one with 3 subtests (one for each flag: 0, DRV, SKB) - Link to v1: https://lore.kernel.org/r/20250103-xdp_redirect-v1-0-e93099f59069@bootlin.c… --- Bastien Curutchet (eBPF Foundation) (3): selftests/bpf: test_xdp_redirect: Rename BPF sections selftests/bpf: Migrate test_xdp_redirect.sh to xdp_do_redirect.c selftests/bpf: Migrate test_xdp_redirect.c to test_xdp_do_redirect.c tools/testing/selftests/bpf/Makefile | 1 - .../selftests/bpf/prog_tests/xdp_do_redirect.c | 164 +++++++++++++++++++++ .../selftests/bpf/progs/test_xdp_do_redirect.c | 12 ++ .../selftests/bpf/progs/test_xdp_redirect.c | 26 ---- tools/testing/selftests/bpf/test_xdp_redirect.sh | 79 ---------- 5 files changed, 176 insertions(+), 106 deletions(-) --- base-commit: b27feb5365c6a1bf7e71ba5c795717ee0eec298d change-id: 20241219-xdp_redirect-2b8ec79dc24e Best regards, -- Bastien Curutchet (eBPF Foundation) <bastien.curutchet(a)bootlin.com>

7 months, 4 weeks

3
5
0 0

[PATCH bpf-next] bpf: veristat: Document verifier log dumping capability

by Daniel Xu

`-l2 -v` is a useful combination of flags to dump the entire verification log. This is helpful when making changes to the verifier, as you can see what it thinks program one instruction at a time. This was more or less a hidden feature before. Document it so others can discover it. Signed-off-by: Daniel Xu <dxu(a)dxuuu.xyz> --- tools/testing/selftests/bpf/veristat.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/bpf/veristat.c b/tools/testing/selftests/bpf/veristat.c index 974c808f9321..7d0a9cb753e3 100644 --- a/tools/testing/selftests/bpf/veristat.c +++ b/tools/testing/selftests/bpf/veristat.c @@ -216,7 +216,8 @@ const char argp_program_doc[] = "\n" "USAGE: veristat <obj-file> [<obj-file>...]\n" " OR: veristat -C <baseline.csv> <comparison.csv>\n" -" OR: veristat -R <results.csv>\n"; +" OR: veristat -R <results.csv>\n" +" OR: veristat -v -l2 <to_analyze.bpf.o>\n"; enum { OPT_LOG_FIXED = 1000, @@ -228,7 +229,7 @@ static const struct argp_option opts[] = { { "version", 'V', NULL, 0, "Print version" }, { "verbose", 'v', NULL, 0, "Verbose mode" }, { "debug", 'd', NULL, 0, "Debug mode (turns on libbpf debug logging)" }, - { "log-level", 'l', "LEVEL", 0, "Verifier log level (default 0 for normal mode, 1 for verbose mode)" }, + { "log-level", 'l', "LEVEL", 0, "Verifier log level (default 0 for normal mode, 1 for verbose mode, 2 for full verification log)" }, { "log-fixed", OPT_LOG_FIXED, NULL, 0, "Disable verifier log rotation" }, { "log-size", OPT_LOG_SIZE, "BYTES", 0, "Customize verifier log size (default to 16MB)" }, { "top-n", 'n', "N", 0, "Emit only up to first N results." }, -- 2.47.1

7 months, 4 weeks

3
2
0 0

[RFC PATCH v2 0/2] Add file seal to prevent future exec mappings

by Isaac J. Manjarres

Android uses the ashmem driver [1] for creating shared memory regions between processes. The ashmem driver exposes an ioctl command for processes to restrict the permissions an ashmem buffer can be mapped with. Buffers are created with the ability to be mapped as readable, writable, and executable. Processes remove the ability to map some ashmem buffers as executable to ensure that those buffers cannot be used to inject malicious code for another process to run. Other buffers retain their ability to be mapped as executable, as these buffers can be used for just-in-time (JIT) compilation. So there is a need to be able to remove the ability to map a buffer as executable on a per-buffer basis. Android is currently trying to migrate towards replacing its ashmem driver usage with memfd. Part of the transition involved introducing a library that serves to abstract away how shared memory regions are allocated (i.e. ashmem vs memfd). This allows clients to use a single interface for restricting how a buffer can be mapped without having to worry about how it is handled for ashmem (through the ioctl command mentioned earlier) or memfd (through file seals). While memfd has support for preventing buffers from being mapped as writable beyond a certain point in time (thanks to F_SEAL_FUTURE_WRITE), it does not have a similar interface to prevent buffers from being mapped as executable beyond a certain point. However, that could be implemented as a file seal (F_SEAL_FUTURE_EXEC) which works similarly to F_SEAL_FUTURE_WRITE. F_SEAL_FUTURE_WRITE was chosen as a template for how this new seal should behave, instead of F_SEAL_WRITE, for the following reasons: 1. Having the new seal behave like F_SEAL_FUTURE_WRITE matches the behavior that was present with ashmem. This aids in seamlessly transitioning clients away from ashmem to memfd. 2. Making the new seal behave like F_SEAL_WRITE would mean that no mappings that could become executable in the future (i.e. via mprotect()) can exist when the seal is applied. However, there are known cases (e.g. CursorWindow [2]) where restrictions are applied on how a buffer can be mapped after a mapping has already been made. That mapping may have VM_MAYEXEC set, which would not allow the seal to be applied successfully. Therefore, the F_SEAL_FUTURE_EXEC seal was designed to have the same semantics as F_SEAL_FUTURE_WRITE. Note: this series depends on Lorenzo's work [3], [4], [5] from Andrew Morton's mm-unstable branch [6], which reworks memfd's file seal checks, allowing for newer file seals to be implemented in a cleaner fashion. Changes from v1 ==> v2: - Changed the return code to be -EPERM instead of -EACCES when attempting to map an exec sealed file with PROT_EXEC to align to mmap()'s man page. Thank you Kalesh Singh for spotting this! - Rebased on top of Lorenzo's work to cleanup memfd file seal checks in mmap() ([3], [4], and [5]). Thank you for this Lorenzo! - Changed to deny PROT_EXEC mappings only if the mapping is shared, instead of for both shared and private mappings, after discussing this with Lorenzo. Opens: - Lorenzo brought up that this patch may negatively impact the usage of MFD_NOEXEC_SCOPE_NOEXEC_ENFORCED [7]. However, it is not clear to me why that is the case. At the moment, my intent is for the executable permissions of the file to be disjoint from the ability to create executable mappings. Links: [1] https://cs.android.com/android/kernel/superproject/+/common-android-mainlin… [2] https://developer.android.com/reference/android/database/CursorWindow [3] https://lore.kernel.org/all/cover.1732804776.git.lorenzo.stoakes@oracle.com/ [4] https://lkml.kernel.org/r/20241206212846.210835-1-lorenzo.stoakes@oracle.com [5] https://lkml.kernel.org/r/7dee6c5d-480b-4c24-b98e-6fa47dbd8a23@lucifer.local [6] https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/tree/?h=mm-unst… [7] https://lore.kernel.org/all/3a53b154-1e46-45fb-a559-65afa7a8a788@lucifer.lo… Links to previous versions: v1: https://lore.kernel.org/all/20241206010930.3871336-1-isaacmanjarres@google.… Isaac J. Manjarres (2): mm/memfd: Add support for F_SEAL_FUTURE_EXEC to memfd selftests/memfd: Add tests for F_SEAL_FUTURE_EXEC include/uapi/linux/fcntl.h | 1 + mm/memfd.c | 39 ++++++++++- tools/testing/selftests/memfd/memfd_test.c | 79 ++++++++++++++++++++++ 3 files changed, 118 insertions(+), 1 deletion(-) -- 2.47.1.613.gc27f4b7a9f-goog

7 months, 4 weeks

2
3
0 0

[PATCH] landlock: ptrace_test: remove unused macros

by Ba Jing

After reviewing the code, it was found that these macros are never referenced in the code. Just remove them. Signed-off-by: Ba Jing <bajing(a)cmss.chinamobile.com> --- tools/testing/selftests/landlock/ptrace_test.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/tools/testing/selftests/landlock/ptrace_test.c b/tools/testing/selftests/landlock/ptrace_test.c index a19db4d0b3bd..8f31b673ff2d 100644 --- a/tools/testing/selftests/landlock/ptrace_test.c +++ b/tools/testing/selftests/landlock/ptrace_test.c @@ -22,8 +22,6 @@ /* Copied from security/yama/yama_lsm.c */ #define YAMA_SCOPE_DISABLED 0 #define YAMA_SCOPE_RELATIONAL 1 -#define YAMA_SCOPE_CAPABILITY 2 -#define YAMA_SCOPE_NO_ATTACH 3 static void create_domain(struct __test_metadata *const _metadata) { -- 2.33.0

7 months, 4 weeks

2
1
0 0

[PATCH v6 0/6] tun: Introduce virtio-net hashing feature

by Akihiko Odaki

This series depends on: "[PATCH v2 0/3] tun: Unify vnet implementation and fill full vnet header" https://lore.kernel.org/r/20250109-tun-v2-0-388d7d5a287a@daynix.com virtio-net have two usage of hashes: one is RSS and another is hash reporting. Conventionally the hash calculation was done by the VMM. However, computing the hash after the queue was chosen defeats the purpose of RSS. Another approach is to use eBPF steering program. This approach has another downside: it cannot report the calculated hash due to the restrictive nature of eBPF. Introduce the code to compute hashes to the kernel in order to overcome thse challenges. An alternative solution is to extend the eBPF steering program so that it will be able to report to the userspace, but it is based on context rewrites, which is in feature freeze. We can adopt kfuncs, but they will not be UAPIs. We opt to ioctl to align with other relevant UAPIs (KVM and vhost_net). The patches for QEMU to use this new feature was submitted as RFC and is available at: https://patchew.org/QEMU/20240915-hash-v3-0-79cb08d28647@daynix.com/ This work was presented at LPC 2024: https://lpc.events/event/18/contributions/1963/ V1 -> V2: Changed to introduce a new BPF program type. Signed-off-by: Akihiko Odaki <akihiko.odaki(a)daynix.com> --- Changes in v6: - Extracted changes to fill vnet header holes into another series. - Squashed patches "skbuff: Introduce SKB_EXT_TUN_VNET_HASH", "tun: Introduce virtio-net hash reporting feature", and "tun: Introduce virtio-net RSS" into patch "tun: Introduce virtio-net hash feature". - Dropped the RFC tag. - Link to v5: https://lore.kernel.org/r/20241008-rss-v5-0-f3cf68df005d@daynix.com Changes in v5: - Fixed a compilation error with CONFIG_TUN_VNET_CROSS_LE. - Optimized the calculation of the hash value according to: https://git.dpdk.org/dpdk/commit/?id=3fb1ea032bd6ff8317af5dac9af901f1f324ca… - Added patch "tun: Unify vnet implementation". - Dropped patch "tap: Pad virtio header with zero". - Added patch "selftest: tun: Test vnet ioctls without device". - Reworked selftests to skip for older kernels. - Documented the case when the underlying device is deleted and packets have queue_mapping set by TC. - Reordered test harness arguments. - Added code to handle fragmented packets. - Link to v4: https://lore.kernel.org/r/20240924-rss-v4-0-84e932ec0e6c@daynix.com Changes in v4: - Moved tun_vnet_hash_ext to if_tun.h. - Renamed virtio_net_toeplitz() to virtio_net_toeplitz_calc(). - Replaced htons() with cpu_to_be16(). - Changed virtio_net_hash_rss() to return void. - Reordered variable declarations in virtio_net_hash_rss(). - Removed virtio_net_hdr_v1_hash_from_skb(). - Updated messages of "tap: Pad virtio header with zero" and "tun: Pad virtio header with zero". - Fixed vnet_hash allocation size. - Ensured to free vnet_hash when destructing tun_struct. - Link to v3: https://lore.kernel.org/r/20240915-rss-v3-0-c630015db082@daynix.com Changes in v3: - Reverted back to add ioctl. - Split patch "tun: Introduce virtio-net hashing feature" into "tun: Introduce virtio-net hash reporting feature" and "tun: Introduce virtio-net RSS". - Changed to reuse hash values computed for automq instead of performing RSS hashing when hash reporting is requested but RSS is not. - Extracted relevant data from struct tun_struct to keep it minimal. - Added kernel-doc. - Changed to allow calling TUNGETVNETHASHCAP before TUNSETIFF. - Initialized num_buffers with 1. - Added a test case for unclassified packets. - Fixed error handling in tests. - Changed tests to verify that the queue index will not overflow. - Rebased. - Link to v2: https://lore.kernel.org/r/20231015141644.260646-1-akihiko.odaki@daynix.com --- Akihiko Odaki (6): virtio_net: Add functions for hashing net: flow_dissector: Export flow_keys_dissector_symmetric tun: Introduce virtio-net hash feature selftest: tun: Test vnet ioctls without device selftest: tun: Add tests for virtio-net hashing vhost/net: Support VIRTIO_NET_F_HASH_REPORT Documentation/networking/tuntap.rst | 7 + drivers/net/Kconfig | 1 + drivers/net/tap.c | 50 ++- drivers/net/tun.c | 93 ++++-- drivers/net/tun_vnet.c | 167 +++++++++- drivers/net/tun_vnet.h | 33 +- drivers/vhost/net.c | 16 +- include/linux/if_tap.h | 2 + include/linux/skbuff.h | 3 + include/linux/virtio_net.h | 188 +++++++++++ include/net/flow_dissector.h | 1 + include/uapi/linux/if_tun.h | 75 +++++ net/core/flow_dissector.c | 3 +- net/core/skbuff.c | 4 + tools/testing/selftests/net/Makefile | 2 +- tools/testing/selftests/net/tun.c | 630 ++++++++++++++++++++++++++++++++++- 16 files changed, 1224 insertions(+), 51 deletions(-) --- base-commit: 9b2ffa6148b1e4468d08f7e0e7e371c43cac9ffe change-id: 20240403-rss-e737d89efa77 prerequisite-change-id: 20241230-tun-66e10a49b0c7:v2 prerequisite-patch-id: 057e888c371f2ce750064b7c40c2cc6abbdf6819 prerequisite-patch-id: 22d53dd3443a2c72496bffb90f19d429972550a3 prerequisite-patch-id: 1520f0c1f7b11559d0898bea556f745f6b8914ac Best regards, -- Akihiko Odaki <akihiko.odaki(a)daynix.com>

8 months

3
14
0 0

[PATCH 0/6] ptrace: introduce PTRACE_SET_SYSCALL_INFO API

by Dmitry V. Levin

PTRACE_SET_SYSCALL_INFO is a generic ptrace API that complements PTRACE_GET_SYSCALL_INFO by letting the ptracer modify details of system calls the tracee is blocked in. This API allows ptracers to obtain and modify system call details in a straightforward and architecture-agnostic way. Current implementation supports changing only those bits of system call information that are used by strace, namely, syscall number, syscall arguments, and syscall return value. Support of changing additional details returned by PTRACE_GET_SYSCALL_INFO, such as instruction pointer and stack pointer, could be added later if needed, by re-using struct ptrace_syscall_info.reserved to specify the additional details that should be set. Currently, the reserved field of struct ptrace_syscall_info must be initialized with zeroes; arch, instruction_pointer, and stack_pointer fields are ignored. PTRACE_SET_SYSCALL_INFO currently supports only PTRACE_SYSCALL_INFO_ENTRY, PTRACE_SYSCALL_INFO_EXIT, and PTRACE_SYSCALL_INFO_SECCOMP operations. Other operations could be added later if needed. Ideally, PTRACE_SET_SYSCALL_INFO should have been introduced along with PTRACE_GET_SYSCALL_INFO, but it didn't happen. The last straw that convinced me to implement PTRACE_SET_SYSCALL_INFO was apparent failure to provide an API of changing the first system call argument on riscv architecture [1]. ptrace(2) man page: long ptrace(enum __ptrace_request request, pid_t pid, void *addr, void *data); ... PTRACE_SET_SYSCALL_INFO Modify information about the system call that caused the stop. The "data" argument is a pointer to struct ptrace_syscall_info that specifies the system call information to be set. The "addr" argument should be set to sizeof(struct ptrace_syscall_info)). [1] https://lore.kernel.org/all/59505464-c84a-403d-972f-d4b2055eeaac@gmail.com/ Dmitry V. Levin (6): Revert "arch: remove unused function syscall_set_arguments()" syscall.h: add syscall_set_arguments() on remaining HAVE_ARCH_TRACEHOOK arches syscall.h: introduce syscall_set_nr() ptrace_get_syscall_info: factor out ptrace_get_syscall_info_op ptrace: introduce PTRACE_SET_SYSCALL_INFO request selftests/ptrace: add a test case for PTRACE_SET_SYSCALL_INFO arch/arc/include/asm/syscall.h | 20 + arch/arm/include/asm/syscall.h | 25 + arch/arm64/include/asm/syscall.h | 20 + arch/csky/include/asm/syscall.h | 13 + arch/hexagon/include/asm/syscall.h | 14 + arch/loongarch/include/asm/syscall.h | 15 + arch/m68k/include/asm/syscall.h | 7 + arch/microblaze/include/asm/syscall.h | 7 + arch/mips/include/asm/syscall.h | 53 +++ arch/nios2/include/asm/syscall.h | 16 + arch/openrisc/include/asm/syscall.h | 13 + arch/parisc/include/asm/syscall.h | 19 + arch/powerpc/include/asm/syscall.h | 15 + arch/riscv/include/asm/syscall.h | 16 + arch/s390/include/asm/syscall.h | 19 + arch/sh/include/asm/syscall_32.h | 19 + arch/sparc/include/asm/syscall.h | 17 + arch/um/include/asm/syscall-generic.h | 19 + arch/x86/include/asm/syscall.h | 43 ++ arch/xtensa/include/asm/syscall.h | 18 + include/asm-generic/syscall.h | 30 ++ include/linux/ptrace.h | 3 + include/uapi/linux/ptrace.h | 3 +- kernel/ptrace.c | 154 ++++++- tools/testing/selftests/ptrace/Makefile | 2 +- .../selftests/ptrace/set_syscall_info.c | 436 ++++++++++++++++++ 26 files changed, 994 insertions(+), 22 deletions(-) create mode 100644 tools/testing/selftests/ptrace/set_syscall_info.c -- ldv

8 months

2
2
0 0

[PATCH net-next v3 0/4] netconsole: selftest for userdata overflow

by Breno Leitao

Implement comprehensive testing for netconsole userdata entry handling, demonstrating correct behavior when creating maximum entries and preventing unauthorized overflow. Refactor existing test infrastructure to support modular, reusable helper functions that validate strict entry limit enforcement. Also, add a warning if update_userdata() sees more than MAX_USERDATA_ITEMS entries. This shouldn't happen and it is a bug that shouldn't be silently ignored. Signed-off-by: Breno Leitao <leitao(a)debian.org> --- Changes in v3: - Added the new shell helpers files in the TEST_INCLUDES (Jakub) - Link to v2: https://lore.kernel.org/r/20250103-netcons_overflow_test-v2-0-a49f9be64c21@… Changes in v2: - Add the new script (netcons_overflow.sh) in tools/testing/selftests/drivers/net/Makefile as suggested by Simon Horman - Link to v1: https://lore.kernel.org/r/20241204-netcons_overflow_test-v1-0-a85a8d0ace21@… --- Breno Leitao (4): netconsole: Warn if MAX_USERDATA_ITEMS limit is exceeded netconsole: selftest: Split the helpers from the selftest netconsole: selftest: Delete all userdata keys netconsole: selftest: verify userdata entry limit MAINTAINERS | 3 +- drivers/net/netconsole.c | 2 +- tools/testing/selftests/drivers/net/Makefile | 2 + .../selftests/drivers/net/lib/sh/lib_netcons.sh | 225 +++++++++++++++++++++ .../testing/selftests/drivers/net/netcons_basic.sh | 218 +------------------- .../selftests/drivers/net/netcons_overflow.sh | 67 ++++++ 6 files changed, 298 insertions(+), 219 deletions(-) --- base-commit: 7bf1659bad4e9413cdba132ef9cbd0caa9cabcc4 change-id: 20241204-netcons_overflow_test-eaf735d1f743 Best regards, -- Breno Leitao <leitao(a)debian.org>

8 months

2
5
0 0

[PATCH 0/2] selftest: fix riscv/vector tests

by Yong-Xuan Wang

Add test counts and pass message to remove warning of riscv/vector tests. Yong-Xuan Wang (2): tools: selftests: riscv: Add pass message for v_initval_nolibc tools: selftests: riscv: Add test count for vstate_prctl tools/testing/selftests/riscv/vector/v_initval_nolibc.c | 4 ++++ tools/testing/selftests/riscv/vector/vstate_prctl.c | 2 ++ 2 files changed, 6 insertions(+) -- 2.17.1

8 months

5
6
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror January 2025