July 2024 - Linux-kselftest-mirror

[PATCH bpf-next 0/4] use network helpers, part 10

by Geliang Tang

From: Geliang Tang <tanggeliang(a)kylinos.cn> This set is part 10 of series "use network helpers" all BPF selftests wide. Patches 1-3 drop local functions make_client(), make_socket() and inetaddr_len() in sk_lookup.c. Patch 4 drops a useless function __start_server() in network_helpers.c. Geliang Tang (4): selftests/bpf: Drop make_client in sk_lookup selftests/bpf: Drop make_socket in sk_lookup selftests/bpf: Drop inetaddr_len in sk_lookup selftests/bpf: Drop __start_server in network_helpers tools/testing/selftests/bpf/network_helpers.c | 26 ++--- .../selftests/bpf/prog_tests/sk_lookup.c | 110 +++++------------- 2 files changed, 40 insertions(+), 96 deletions(-) -- 2.43.0

10 months, 3 weeks

2
5
0 0

[PATCH bpf-next v4 00/20] Add return value range check for BPF LSM

by Xu Kuohai

From: Xu Kuohai <xukuohai(a)huawei.com> LSM BPF prog returning a positive number attached to the hook file_alloc_security makes kernel panic. Here is a panic log: [ 441.235774] BUG: kernel NULL pointer dereference, address: 00000000000009 [ 441.236748] #PF: supervisor write access in kernel mode [ 441.237429] #PF: error_code(0x0002) - not-present page [ 441.238119] PGD 800000000b02f067 P4D 800000000b02f067 PUD b031067 PMD 0 [ 441.238990] Oops: 0002 [#1] PREEMPT SMP PTI [ 441.239546] CPU: 0 PID: 347 Comm: loader Not tainted 6.8.0-rc6-gafe0cbf23373 #22 [ 441.240496] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b4 [ 441.241933] RIP: 0010:alloc_file+0x4b/0x190 [ 441.242485] Code: 8b 04 25 c0 3c 1f 00 48 8b b0 30 0c 00 00 e8 9c fe ff ff 48 3d 00 f0 ff fb [ 441.244820] RSP: 0018:ffffc90000c67c40 EFLAGS: 00010203 [ 441.245484] RAX: ffff888006a891a0 RBX: ffffffff8223bd00 RCX: 0000000035b08000 [ 441.246391] RDX: ffff88800b95f7b0 RSI: 00000000001fc110 RDI: f089cd0b8088ffff [ 441.247294] RBP: ffffc90000c67c58 R08: 0000000000000001 R09: 0000000000000001 [ 441.248209] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000001 [ 441.249108] R13: ffffc90000c67c78 R14: ffffffff8223bd00 R15: fffffffffffffff4 [ 441.250007] FS: 00000000005f3300(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 441.251053] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 441.251788] CR2: 00000000000001a9 CR3: 000000000bdc4003 CR4: 0000000000170ef0 [ 441.252688] Call Trace: [ 441.253011] <TASK> [ 441.253296] ? __die+0x24/0x70 [ 441.253702] ? page_fault_oops+0x15b/0x480 [ 441.254236] ? fixup_exception+0x26/0x330 [ 441.254750] ? exc_page_fault+0x6d/0x1c0 [ 441.255257] ? asm_exc_page_fault+0x26/0x30 [ 441.255792] ? alloc_file+0x4b/0x190 [ 441.256257] alloc_file_pseudo+0x9f/0xf0 [ 441.256760] __anon_inode_getfile+0x87/0x190 [ 441.257311] ? lock_release+0x14e/0x3f0 [ 441.257808] bpf_link_prime+0xe8/0x1d0 [ 441.258315] bpf_tracing_prog_attach+0x311/0x570 [ 441.258916] ? __pfx_bpf_lsm_file_alloc_security+0x10/0x10 [ 441.259605] __sys_bpf+0x1bb7/0x2dc0 [ 441.260070] __x64_sys_bpf+0x20/0x30 [ 441.260533] do_syscall_64+0x72/0x140 [ 441.261004] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 441.261643] RIP: 0033:0x4b0349 [ 441.262045] Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 88 [ 441.264355] RSP: 002b:00007fff74daee38 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 [ 441.265293] RAX: ffffffffffffffda RBX: 00007fff74daef30 RCX: 00000000004b0349 [ 441.266187] RDX: 0000000000000040 RSI: 00007fff74daee50 RDI: 000000000000001c [ 441.267114] RBP: 000000000000001b R08: 00000000005ef820 R09: 0000000000000000 [ 441.268018] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000004 [ 441.268907] R13: 0000000000000004 R14: 00000000005ef018 R15: 00000000004004e8 This is because the filesystem uses IS_ERR to check if the return value is an error code. If it is not, the filesystem takes the return value as a file pointer. Since the positive number returned by the BPF prog is not a real file pointer, this misinterpretation causes a panic. Since other LSM modules always return either a negative error code or a valid pointer, this specific issue only exists in BPF LSM. The proposed solution is to reject LSM BPF progs returning unexpected values in the verifier. This patch set adds return value check to ensure only BPF progs returning expected values are accepted. Since each LSM hook has different excepted return values, we need to know the expected return values for each individual hook to do the check. Earlier versions of the patch set used LSM hook annotations to specify the return value range for each hook. Based on Paul's suggestion, current version gets rid of such annotations and instead converts hook return values to a common pattern: return 0 on success and negative error code on failure. Basically, LSM hooks are divided into two types: hooks that return a negative error code and zero or other values, and hooks that do not return a negative error code. This patch set converts all hooks of the first type and part of the second type to return 0 on success and a negative error code on failure (see patches 1-10). For certain hooks, like ismaclabel and inode_xattr_skipcap, the hook name already imply that returning 0 or 1 is the best choice, so they are not converted. There are four unconverted hooks. Except for ismaclabel, which is not used by BPF LSM, the other three are specified with a BTF ID list to only return 0 or 1. v4: 1. remove LSM_HOOK return value annotaion and convert LSM hook return value to a common patern: return 0 on success and negative error code on failure (patch 1-10) 2. enable BPF LSM progs to read and write output params (patch 12) 3. add a special case for bitwise AND on range [-1, 0] (patch 16) 4. add a 32-bit comparing flag for retval_range_within (patch 15) 5. collect ACKs, style fix, etc v3: https://lore.kernel.org/bpf/20240411122752.2873562-1-xukuohai@huaweicloud.c… 1. Fix incorrect lsm hook return value ranges, and add disabled hook list for bpf lsm, and merge two LSM_RET_INT patches. (KP Singh) 2. Avoid bpf lsm progs attached to different hooks to call each other with tail call 3. Fix a CI failure caused by false rejection of AND operation 4. Add tests v2: https://lore.kernel.org/bpf/20240325095653.1720123-1-xukuohai@huaweicloud.c… fix bpf ci failure v1: https://lore.kernel.org/bpf/20240316122359.1073787-1-xukuohai@huaweicloud.c… Xu Kuohai (20): lsm: Refactor return value of LSM hook vm_enough_memory lsm: Refactor return value of LSM hook inode_need_killpriv lsm: Refactor return value of LSM hook inode_getsecurity lsm: Refactor return value of LSM hook inode_listsecurity lsm: Refactor return value of LSM hook inode_copy_up_xattr lsm: Refactor return value of LSM hook getselfattr lsm: Refactor return value of LSM hook setprocattr lsm: Refactor return value of LSM hook getprocattr lsm: Refactor return value of LSM hook key_getsecurity lsm: Refactor return value of LSM hook audit_rule_match bpf, lsm: Add disabled BPF LSM hook list bpf, lsm: Enable BPF LSM prog to read/write return value parameters bpf, lsm: Add check for BPF LSM return value bpf: Prevent tail call between progs attached to different hooks bpf: Fix compare error in function retval_range_within bpf: Add a special case for bitwise AND on range [-1, 0] selftests/bpf: Avoid load failure for token_lsm.c selftests/bpf: Add return value checks for failed tests selftests/bpf: Add test for lsm tail call selftests/bpf: Add verifier tests for bpf lsm fs/attr.c | 5 +- fs/inode.c | 4 +- fs/nfs/nfs4proc.c | 5 +- fs/overlayfs/copy_up.c | 6 +- fs/proc/base.c | 10 +- fs/xattr.c | 24 +- include/linux/bpf.h | 2 + include/linux/bpf_lsm.h | 15 + include/linux/lsm_hook_defs.h | 22 +- include/linux/security.h | 62 ++-- include/linux/tnum.h | 3 + kernel/bpf/bpf_lsm.c | 64 +++- kernel/bpf/btf.c | 21 +- kernel/bpf/core.c | 21 +- kernel/bpf/tnum.c | 25 ++ kernel/bpf/verifier.c | 173 ++++++++++- net/socket.c | 9 +- security/apparmor/audit.c | 22 +- security/apparmor/include/audit.h | 2 +- security/apparmor/lsm.c | 22 +- security/commoncap.c | 32 +- security/integrity/evm/evm_main.c | 2 +- security/keys/keyctl.c | 11 +- security/lsm_syscalls.c | 6 +- security/security.c | 167 ++++++++--- security/selinux/hooks.c | 94 +++--- security/selinux/include/audit.h | 8 +- security/selinux/ss/services.c | 54 ++-- security/smack/smack_lsm.c | 104 ++++--- .../selftests/bpf/prog_tests/test_lsm.c | 46 ++- .../selftests/bpf/prog_tests/verifier.c | 2 + tools/testing/selftests/bpf/progs/err.h | 10 + .../selftests/bpf/progs/lsm_tailcall.c | 34 +++ .../selftests/bpf/progs/test_sig_in_xattr.c | 4 + .../bpf/progs/test_verify_pkcs7_sig.c | 8 +- tools/testing/selftests/bpf/progs/token_lsm.c | 4 +- .../bpf/progs/verifier_global_subprogs.c | 7 +- .../selftests/bpf/progs/verifier_lsm.c | 274 ++++++++++++++++++ 38 files changed, 1098 insertions(+), 286 deletions(-) create mode 100644 tools/testing/selftests/bpf/progs/lsm_tailcall.c create mode 100644 tools/testing/selftests/bpf/progs/verifier_lsm.c -- 2.30.2

10 months, 3 weeks

6
46
0 0

[PATCH v4 0/2] Add test to distinguish between thread's signal mask and ucontext_t

by Dev Jain

This patch series is motivated by the following observation: Raise a signal, jump to signal handler. The ucontext_t structure dumped by kernel to userspace has a uc_sigmask field having the mask of blocked signals. If you run a fresh minimalistic program doing this, this field is empty, even if you block some signals while registering the handler with sigaction(). Here is what the man-pages have to say: sigaction(2): "sa_mask specifies a mask of signals which should be blocked (i.e., added to the signal mask of the thread in which the signal handler is invoked) during execution of the signal handler. In addition, the signal which triggered the handler will be blocked, unless the SA_NODEFER flag is used." signal(7): Under "Execution of signal handlers", (1.3) implies: "The thread's current signal mask is accessible via the ucontext_t object that is pointed to by the third argument of the signal handler." But, (1.4) states: "Any signals specified in act->sa_mask when registering the handler with sigprocmask(2) are added to the thread's signal mask. The signal being delivered is also added to the signal mask, unless SA_NODEFER was specified when registering the handler. These signals are thus blocked while the handler executes." There clearly is no distinction being made in the man pages between "Thread's signal mask" and ucontext_t; this logically should imply that a signal blocked by populating struct sigaction should be visible in ucontext_t. Here is what the kernel code does (for Aarch64): do_signal() -> handle_signal() -> sigmask_to_save(), which returns &current->blocked, is passed to setup_rt_frame() -> setup_sigframe() -> __copy_to_user(). Hence, &current->blocked is copied to ucontext_t exposed to userspace. Returning back to handle_signal(), signal_setup_done() -> signal_delivered() -> sigorsets() and set_current_blocked() are responsible for using information from struct ksignal ksig, which was populated through the sigaction() system call in kernel/signal.c: copy_from_user(&new_sa.sa, act, sizeof(new_sa.sa)), to update &current->blocked; hence, the set of blocked signals for the current thread is updated AFTER the kernel dumps ucontext_t to userspace. Assuming that the above is indeed the intended behaviour, because it semantically makes sense, since the signals blocked using sigaction() remain blocked only till the execution of the handler, and not in the context present before jumping to the handler (but nothing can be confirmed from the man-pages), the series introduces a test for mangling with uc_sigmask. I will send a separate series to fix the man-pages. The proposed selftest has been tested out on Aarch32, Aarch64 and x86_64. v3->v4: - Allocate sigsets as automatic variables to avoid malloc() v2->v3: - ucontext describes current state -> ucontext describes interrupted context - Add a comment for blockage of USR2 even after return from handler - Describe blockage of signals in a better way v1->v2: - Replace all occurrences of SIGPIPE with SIGSEGV - Fixed a mismatch between code comment and ksft log - Add a testcase: Raise the same signal again; it must not be queued - Remove unneeded <assert.h>, <unistd.h> - Give a detailed test description in the comments; also describe the exact meaning of delivered and blocked - Handle errors for all libc functions/syscalls - Mention tests in Makefile and .gitignore in alphabetical order v1: - https://lore.kernel.org/all/20240607122319.768640-1-dev.jain@arm.com/ Dev Jain (2): selftests: Rename sigaltstack to generic signal selftests: Add a test mangling with uc_sigmask tools/testing/selftests/Makefile | 2 +- .../{sigaltstack => signal}/.gitignore | 3 +- .../{sigaltstack => signal}/Makefile | 3 +- .../current_stack_pointer.h | 0 .../selftests/signal/mangle_uc_sigmask.c | 186 ++++++++++++++++++ .../sas.c => signal/sigaltstack.c} | 0 6 files changed, 191 insertions(+), 3 deletions(-) rename tools/testing/selftests/{sigaltstack => signal}/.gitignore (57%) rename tools/testing/selftests/{sigaltstack => signal}/Makefile (53%) rename tools/testing/selftests/{sigaltstack => signal}/current_stack_pointer.h (100%) create mode 100644 tools/testing/selftests/signal/mangle_uc_sigmask.c rename tools/testing/selftests/{sigaltstack/sas.c => signal/sigaltstack.c} (100%) -- 2.34.1

10 months, 3 weeks

4
9
0 0

[PATCH] kselftest: missing arg in ptrace.c

by Remington Brasga

The string passed to ksft_test_result_skip is missing the `type_name` Signed-off-by: Remington Brasga <rbrasga(a)uci.edu> --- clang-tidy reported clang-diagnostic-format-insufficient-args warning on this line, so I am fixing it. tools/testing/selftests/arm64/abi/ptrace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/arm64/abi/ptrace.c b/tools/testing/selftests/arm64/abi/ptrace.c index abe4d58d731d..6144f83f8ab4 100644 --- a/tools/testing/selftests/arm64/abi/ptrace.c +++ b/tools/testing/selftests/arm64/abi/ptrace.c @@ -156,7 +156,7 @@ static void test_hw_debug(pid_t child, int type, const char *type_name) /* Zero is not currently architecturally valid */ ksft_test_result(arch, "%s_arch_set\n", type_name); } else { - ksft_test_result_skip("%s_arch_set\n"); + ksft_test_result_skip("%s_arch_set\n", type_name); } } -- 2.34.1

10 months, 3 weeks

4
6
0 0

Recommendations for Optimizing Linux Kernel for ARM Architecture

by Selena Thomas

Hi everyone, I'm currently working on optimizing the Linux kernel for an ARM-based project and would appreciate some guidance. I've already gone through the basics of kernel configuration, but I'm looking for more advanced tips. Specifically, I'm interested in: Best practices for enabling/disabling specific kernel features for ARM. Effective ways to profile and analyze performance bottlenecks. Recommendations for debugging tools tailored for ARM architecture. Any common pitfalls to avoid during the optimization process. If you have any experiences or resources to share, I'd be very grateful. Looking forward to your insights! Best, Selena Thomas https://www.igmguru.com/data-science-bi/msbi-certification-training/

10 months, 3 weeks

1
0
0 0

Recommendations for Optimizing Linux Kernel for ARM Architecture

by Selena Thomas

Hi everyone, I'm currently working on optimizing the Linux kernel for an ARM-based project and would appreciate some guidance. I've already gone through the basics of kernel configuration, but I'm looking for more advanced tips. Specifically, I'm interested in: Best practices for enabling/disabling specific kernel features for ARM. Effective ways to profile and analyze performance bottlenecks. Recommendations for debugging tools tailored for ARM architecture. Any common pitfalls to avoid during the optimization process. If you have any experiences or resources to share, I'd be very grateful. Looking forward to your insights! Best regards Selena

10 months, 3 weeks

1
0
0 0

[PATCH v6 00/13] riscv: Add support for xtheadvector

by Charlie Jenkins

xtheadvector is a custom extension that is based upon riscv vector version 0.7.1 [1]. All of the vector routines have been modified to support this alternative vector version based upon whether xtheadvector was determined to be supported at boot. vlenb is not supported on the existing xtheadvector hardware, so a devicetree property thead,vlenb is added to provide the vlenb to Linux. There is a new hwprobe key RISCV_HWPROBE_KEY_VENDOR_EXT_THEAD_0 that is used to request which thead vendor extensions are supported on the current platform. This allows future vendors to allocate hwprobe keys for their vendor. Support for xtheadvector is also added to the vector kselftests. Signed-off-by: Charlie Jenkins <charlie(a)rivosinc.com> [1] https://github.com/T-head-Semi/thead-extension-spec/blob/95358cb2cca9489361… --- This series is a continuation of a different series that was fragmented into two other series in an attempt to get part of it merged in the 6.10 merge window. The split-off series did not get merged due to a NAK on the series that added the generic riscv,vlenb devicetree entry. This series has converted riscv,vlenb to thead,vlenb to remedy this issue. The original series is titled "riscv: Support vendor extensions and xtheadvector" [3]. The series titled "riscv: Extend cpufeature.c to detect vendor extensions" is still under development and this series is based on that series! [4] I have tested this with an Allwinner Nezha board. I ran into issues booting the board after 6.9-rc1 so I applied these patches to 6.8. There are a couple of minor merge conflicts that do arrise when doing that, so please let me know if you have been able to boot this board with a 6.9 kernel. I used SkiffOS [1] to manage building the image, but upgraded the U-Boot version to Samuel Holland's more up-to-date version [2] and changed out the device tree used by U-Boot with the device trees that are present in upstream linux and this series. Thank you Samuel for all of the work you did to make this task possible. [1] https://github.com/skiffos/SkiffOS/tree/master/configs/allwinner/nezha [2] https://github.com/smaeul/u-boot/commit/2e89b706f5c956a70c989cd31665f1429e9… [3] https://lore.kernel.org/all/20240503-dev-charlie-support_thead_vector_6_9-v… [4] https://lore.kernel.org/lkml/20240719-support_vendor_extensions-v3-4-0af758… --- Changes in v6: - Fix return type of is_vector_supported()/is_xthead_supported() to be bool - Link to v5: https://lore.kernel.org/r/20240719-xtheadvector-v5-0-4b485fc7d55f@rivosinc.… Changes in v5: - Rebase on for-next - Link to v4: https://lore.kernel.org/r/20240702-xtheadvector-v4-0-2bad6820db11@rivosinc.… Changes in v4: - Replace inline asm with C (Samuel) - Rename VCSRs to CSRs (Samuel) - Replace .insn directives with .4byte directives - Link to v3: https://lore.kernel.org/r/20240619-xtheadvector-v3-0-bff39eb9668e@rivosinc.… Changes in v3: - Add back Heiko's signed-off-by (Conor) - Mark RISCV_HWPROBE_KEY_VENDOR_EXT_THEAD_0 as a bitmask - Link to v2: https://lore.kernel.org/r/20240610-xtheadvector-v2-0-97a48613ad64@rivosinc.… Changes in v2: - Removed extraneous references to "riscv,vlenb" (Jess) - Moved declaration of "thead,vlenb" into cpus.yaml and added restriction that it's only applicable to thead cores (Conor) - Check CONFIG_RISCV_ISA_XTHEADVECTOR instead of CONFIG_RISCV_ISA_V for thead,vlenb (Jess) - Fix naming of hwprobe variables (Evan) - Link to v1: https://lore.kernel.org/r/20240609-xtheadvector-v1-0-3fe591d7f109@rivosinc.… --- Charlie Jenkins (12): dt-bindings: riscv: Add xtheadvector ISA extension description dt-bindings: cpus: add a thead vlen register length property riscv: dts: allwinner: Add xtheadvector to the D1/D1s devicetree riscv: Add thead and xtheadvector as a vendor extension riscv: vector: Use vlenb from DT for thead riscv: csr: Add CSR encodings for CSR_VXRM/CSR_VXSAT riscv: Add xtheadvector instruction definitions riscv: vector: Support xtheadvector save/restore riscv: hwprobe: Add thead vendor extension probing riscv: hwprobe: Document thead vendor extensions and xtheadvector extension selftests: riscv: Fix vector tests selftests: riscv: Support xtheadvector in vector tests Heiko Stuebner (1): RISC-V: define the elements of the VCSR vector CSR Documentation/arch/riscv/hwprobe.rst | 10 + Documentation/devicetree/bindings/riscv/cpus.yaml | 19 ++ .../devicetree/bindings/riscv/extensions.yaml | 10 + arch/riscv/Kconfig.vendor | 26 ++ arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 3 +- arch/riscv/include/asm/cpufeature.h | 2 + arch/riscv/include/asm/csr.h | 15 ++ arch/riscv/include/asm/hwprobe.h | 5 +- arch/riscv/include/asm/switch_to.h | 2 +- arch/riscv/include/asm/vector.h | 223 ++++++++++++---- arch/riscv/include/asm/vendor_extensions/thead.h | 42 +++ .../include/asm/vendor_extensions/thead_hwprobe.h | 18 ++ .../include/asm/vendor_extensions/vendor_hwprobe.h | 37 +++ arch/riscv/include/uapi/asm/hwprobe.h | 3 +- arch/riscv/include/uapi/asm/vendor/thead.h | 3 + arch/riscv/kernel/cpufeature.c | 54 +++- arch/riscv/kernel/kernel_mode_vector.c | 8 +- arch/riscv/kernel/process.c | 4 +- arch/riscv/kernel/signal.c | 6 +- arch/riscv/kernel/sys_hwprobe.c | 5 + arch/riscv/kernel/vector.c | 24 +- arch/riscv/kernel/vendor_extensions.c | 10 + arch/riscv/kernel/vendor_extensions/Makefile | 2 + arch/riscv/kernel/vendor_extensions/thead.c | 18 ++ .../riscv/kernel/vendor_extensions/thead_hwprobe.c | 19 ++ tools/testing/selftests/riscv/vector/.gitignore | 3 +- tools/testing/selftests/riscv/vector/Makefile | 17 +- .../selftests/riscv/vector/v_exec_initval_nolibc.c | 93 +++++++ tools/testing/selftests/riscv/vector/v_helpers.c | 68 +++++ tools/testing/selftests/riscv/vector/v_helpers.h | 8 + tools/testing/selftests/riscv/vector/v_initval.c | 22 ++ .../selftests/riscv/vector/v_initval_nolibc.c | 68 ----- .../selftests/riscv/vector/vstate_exec_nolibc.c | 20 +- .../testing/selftests/riscv/vector/vstate_prctl.c | 295 ++++++++++++--------- 34 files changed, 889 insertions(+), 273 deletions(-) --- base-commit: 554462ced9ac97487c8f725fe466a9c20ed87521 change-id: 20240530-xtheadvector-833d3d17b423 -- - Charlie

10 months, 3 weeks

2
14
0 0

[PATCH] mm, memcg: cg2 memory{.swap,}.peak write handlers (fd-local edition)

by David Finkel

My last patch[1] was met with a general desire for a safer scheme that avoided global resets, which expose unclear ownership. Fortunately, Johannes[2] suggested a reasonably simple scheme to provide an FD-local reset, which eliminates most of those issues. The one open question I have is whether the cgroup/memcg itself is kept alive by an open FD, or if we need to update the memcg freeing code to traverse the new list of "watchers" so they don't try to access freed memory. Thank you, David Finkel Senior Principal Software Engineer, Core Services Vimeo Inc. [1]: https://lore.kernel.org/cgroups/20240715203625.1462309-1-davidf@vimeo.com/ [2]: https://lore.kernel.org/cgroups/20240717170408.GC1321673@cmpxchg.org/

10 months, 3 weeks

3
5
0 0

[PATCH v5 00/13] riscv: Add support for xtheadvector

by Charlie Jenkins

xtheadvector is a custom extension that is based upon riscv vector version 0.7.1 [1]. All of the vector routines have been modified to support this alternative vector version based upon whether xtheadvector was determined to be supported at boot. vlenb is not supported on the existing xtheadvector hardware, so a devicetree property thead,vlenb is added to provide the vlenb to Linux. There is a new hwprobe key RISCV_HWPROBE_KEY_VENDOR_EXT_THEAD_0 that is used to request which thead vendor extensions are supported on the current platform. This allows future vendors to allocate hwprobe keys for their vendor. Support for xtheadvector is also added to the vector kselftests. Signed-off-by: Charlie Jenkins <charlie(a)rivosinc.com> [1] https://github.com/T-head-Semi/thead-extension-spec/blob/95358cb2cca9489361… --- This series is a continuation of a different series that was fragmented into two other series in an attempt to get part of it merged in the 6.10 merge window. The split-off series did not get merged due to a NAK on the series that added the generic riscv,vlenb devicetree entry. This series has converted riscv,vlenb to thead,vlenb to remedy this issue. The original series is titled "riscv: Support vendor extensions and xtheadvector" [3]. The series titled "riscv: Extend cpufeature.c to detect vendor extensions" is still under development and this series is based on that series! [4] I have tested this with an Allwinner Nezha board. I ran into issues booting the board after 6.9-rc1 so I applied these patches to 6.8. There are a couple of minor merge conflicts that do arrise when doing that, so please let me know if you have been able to boot this board with a 6.9 kernel. I used SkiffOS [1] to manage building the image, but upgraded the U-Boot version to Samuel Holland's more up-to-date version [2] and changed out the device tree used by U-Boot with the device trees that are present in upstream linux and this series. Thank you Samuel for all of the work you did to make this task possible. [1] https://github.com/skiffos/SkiffOS/tree/master/configs/allwinner/nezha [2] https://github.com/smaeul/u-boot/commit/2e89b706f5c956a70c989cd31665f1429e9… [3] https://lore.kernel.org/all/20240503-dev-charlie-support_thead_vector_6_9-v… [4] https://lore.kernel.org/linux-riscv/20240609-support_vendor_extensions-v2-0… --- Changes in v5: - Rebase on for-next - Link to v4: https://lore.kernel.org/r/20240702-xtheadvector-v4-0-2bad6820db11@rivosinc.… Changes in v4: - Replace inline asm with C (Samuel) - Rename VCSRs to CSRs (Samuel) - Replace .insn directives with .4byte directives - Link to v3: https://lore.kernel.org/r/20240619-xtheadvector-v3-0-bff39eb9668e@rivosinc.… Changes in v3: - Add back Heiko's signed-off-by (Conor) - Mark RISCV_HWPROBE_KEY_VENDOR_EXT_THEAD_0 as a bitmask - Link to v2: https://lore.kernel.org/r/20240610-xtheadvector-v2-0-97a48613ad64@rivosinc.… Changes in v2: - Removed extraneous references to "riscv,vlenb" (Jess) - Moved declaration of "thead,vlenb" into cpus.yaml and added restriction that it's only applicable to thead cores (Conor) - Check CONFIG_RISCV_ISA_XTHEADVECTOR instead of CONFIG_RISCV_ISA_V for thead,vlenb (Jess) - Fix naming of hwprobe variables (Evan) - Link to v1: https://lore.kernel.org/r/20240609-xtheadvector-v1-0-3fe591d7f109@rivosinc.… --- Charlie Jenkins (12): dt-bindings: riscv: Add xtheadvector ISA extension description dt-bindings: cpus: add a thead vlen register length property riscv: dts: allwinner: Add xtheadvector to the D1/D1s devicetree riscv: Add thead and xtheadvector as a vendor extension riscv: vector: Use vlenb from DT for thead riscv: csr: Add CSR encodings for CSR_VXRM/CSR_VXSAT riscv: Add xtheadvector instruction definitions riscv: vector: Support xtheadvector save/restore riscv: hwprobe: Add thead vendor extension probing riscv: hwprobe: Document thead vendor extensions and xtheadvector extension selftests: riscv: Fix vector tests selftests: riscv: Support xtheadvector in vector tests Heiko Stuebner (1): RISC-V: define the elements of the VCSR vector CSR Documentation/arch/riscv/hwprobe.rst | 10 + Documentation/devicetree/bindings/riscv/cpus.yaml | 19 ++ .../devicetree/bindings/riscv/extensions.yaml | 10 + arch/riscv/Kconfig.vendor | 26 ++ arch/riscv/boot/dts/allwinner/sun20i-d1s.dtsi | 3 +- arch/riscv/include/asm/cpufeature.h | 2 + arch/riscv/include/asm/csr.h | 15 ++ arch/riscv/include/asm/hwprobe.h | 5 +- arch/riscv/include/asm/switch_to.h | 2 +- arch/riscv/include/asm/vector.h | 223 ++++++++++++---- arch/riscv/include/asm/vendor_extensions/thead.h | 42 +++ .../include/asm/vendor_extensions/thead_hwprobe.h | 18 ++ .../include/asm/vendor_extensions/vendor_hwprobe.h | 37 +++ arch/riscv/include/uapi/asm/hwprobe.h | 3 +- arch/riscv/include/uapi/asm/vendor/thead.h | 3 + arch/riscv/kernel/cpufeature.c | 54 +++- arch/riscv/kernel/kernel_mode_vector.c | 8 +- arch/riscv/kernel/process.c | 4 +- arch/riscv/kernel/signal.c | 6 +- arch/riscv/kernel/sys_hwprobe.c | 5 + arch/riscv/kernel/vector.c | 24 +- arch/riscv/kernel/vendor_extensions.c | 10 + arch/riscv/kernel/vendor_extensions/Makefile | 2 + arch/riscv/kernel/vendor_extensions/thead.c | 18 ++ .../riscv/kernel/vendor_extensions/thead_hwprobe.c | 19 ++ tools/testing/selftests/riscv/abi/ptrace | Bin 0 -> 759368 bytes tools/testing/selftests/riscv/vector/.gitignore | 3 +- tools/testing/selftests/riscv/vector/Makefile | 17 +- .../selftests/riscv/vector/v_exec_initval_nolibc.c | 93 +++++++ tools/testing/selftests/riscv/vector/v_helpers.c | 67 +++++ tools/testing/selftests/riscv/vector/v_helpers.h | 7 + tools/testing/selftests/riscv/vector/v_initval.c | 22 ++ .../selftests/riscv/vector/v_initval_nolibc.c | 68 ----- .../selftests/riscv/vector/vstate_exec_nolibc.c | 20 +- .../testing/selftests/riscv/vector/vstate_prctl.c | 295 ++++++++++++--------- 35 files changed, 887 insertions(+), 273 deletions(-) --- base-commit: 554462ced9ac97487c8f725fe466a9c20ed87521 change-id: 20240530-xtheadvector-833d3d17b423 -- - Charlie

10 months, 3 weeks

2
17
0 0

[PATCH 1/2] selftests: x86: vdso_restorer: remove manual counting of pass/fail tests

by Muhammad Usama Anjum

Use kselftest wrapper to mark tests pass/fail instead of manually counting. This is needed to return correct exit status. This also improves readability and mainability. Signed-off-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> --- tools/testing/selftests/x86/vdso_restorer.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) diff --git a/tools/testing/selftests/x86/vdso_restorer.c b/tools/testing/selftests/x86/vdso_restorer.c index fe99f24341554..8e173d71291f6 100644 --- a/tools/testing/selftests/x86/vdso_restorer.c +++ b/tools/testing/selftests/x86/vdso_restorer.c @@ -21,6 +21,7 @@ #include <unistd.h> #include <syscall.h> #include <sys/syscall.h> +#include "../kselftest.h" /* Open-code this -- the headers are too messy to easily use them. */ struct real_sigaction { @@ -44,9 +45,10 @@ static void handler_without_siginfo(int sig) int main() { - int nerrs = 0; struct real_sigaction sa; + ksft_print_header(); + void *vdso = dlopen("linux-vdso.so.1", RTLD_LAZY | RTLD_LOCAL | RTLD_NOLOAD); if (!vdso) @@ -57,6 +59,8 @@ int main() return 0; } + ksft_set_plan(2); + memset(&sa, 0, sizeof(sa)); sa.handler = handler_with_siginfo; sa.flags = SA_SIGINFO; @@ -69,12 +73,7 @@ int main() raise(SIGUSR1); - if (handler_called) { - printf("[OK]\tSA_SIGINFO handler returned successfully\n"); - } else { - printf("[FAIL]\tSA_SIGINFO handler was not called\n"); - nerrs++; - } + ksft_test_result(handler_called, "SA_SIGINFO handler returned\n"); printf("[RUN]\tRaise a signal, !SA_SIGINFO, sa.restorer == NULL\n"); @@ -86,10 +85,5 @@ int main() raise(SIGUSR1); - if (handler_called) { - printf("[OK]\t!SA_SIGINFO handler returned successfully\n"); - } else { - printf("[FAIL]\t!SA_SIGINFO handler was not called\n"); - nerrs++; - } + ksft_test_result(handler_called, "SA_SIGINFO handler returned\n"); } -- 2.39.2

10 months, 4 weeks

2
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror July 2024