Re: [PATCH] riscv: selftests: Add signal handling vector tests

Charlie Jenkins writes: > Add two tests to check vector save/restore when a signal is received > during a vector routine. One test ensures that a value is not clobbered > during signal handling. The other verifies that vector registers > modified in the signal handler are properly reflected when

Re: [PATCH bpf-next v5 1/6] bpf/helpers: introduce sleepable bpf_timers

On Wed, Apr 3, 2024 at 6:01 PM Alexei Starovoitov wrote: > > On Wed, Apr 3, 2024 at 11:50 AM Alexei Starovoitov > wrote: > > > > On Wed, Mar 27, 2024 at 10:02 AM Benjamin Tissoires > > wrote: > > > > > goto out; > > > > > } > > > > > + spin_lock(>sleepable_lock); >

Re: [PATCH v3 15/15] powerpc: Add support for suppressing warning backtraces

Guenter Roeck writes: > Add name of functions triggering warning backtraces to the __bug_table > object section to enable support for suppressing WARNING backtraces. > > To limit image size impact, the pointer to the function name is only added > to the __bug_table section if both

Re: [PATCH v3 06/15] net: kunit: Suppress lock warning noise at end of dev_addr_lists tests

On Wed, 3 Apr 2024 06:19:27 -0700 Guenter Roeck wrote: > dev_addr_lists_test generates lock warning noise at the end of tests > if lock debugging is enabled. There are two sets of warnings. > > WARNING: CPU: 0 PID: 689 at kernel/locking/mutex.c:923 >

Re: [PATCH bpf-next v5 1/6] bpf/helpers: introduce sleepable bpf_timers

On Wed, Apr 3, 2024 at 11:50 AM Alexei Starovoitov wrote: > > On Wed, Mar 27, 2024 at 10:02 AM Benjamin Tissoires > wrote: > > > > goto out; > > > > } > > > > + spin_lock(>sleepable_lock); > > > > drop_prog_refcnt(t); > > > > +

Re: [PATCH] riscv: selftests: Add signal handling vector tests

\n\ > > + .option arch, +v\n\ > > + vsetivlix0, 1, e32, ta, ma \n\ > > + vmv.s.x v0, %1 \n\ > > + # Generate SIGSEGV \n\ > > + lw a0, 0(x0) \n\ > > + vmv.x.s %0, v0 \n\ > > + .option pop" : "=r" (after_sigreturn) : "r" (data)); > > + > > + return after_sigreturn; > > +} > > + > > +TEST(vector_restore) > > +{ > > + int result; > > + > > + result = vector_sigreturn(DEFAULT_VALUE, _handle); > > + > > + EXPECT_EQ(DEFAULT_VALUE, result); > > +} > > + > > +TEST(vector_restore_signal_handler_override) > > +{ > > + int result; > > + > > + result = vector_sigreturn(DEFAULT_VALUE, _override); > > + > > + EXPECT_EQ(SIGNAL_HANDLER_OVERRIDE, result); > > +} > > + > > +TEST_HARNESS_MAIN > > > > --- > > base-commit: 4cece764965020c22cff7665b18a012006359095 > > change-id: 20240403-vector_sigreturn_tests-8118f0ac54fa >

Re: [PATCH] riscv: selftests: Add signal handling vector tests

lw a0, 0(x0) \n\ > + vmv.x.s %0, v0 \n\ > + .option pop" : "=r" (after_sigreturn) : "r" (data)); > + > + return after_sigreturn; > +} > + > +TEST(vector_restore) > +{ > + int result; > + > + result = vector_sigreturn(DEFAULT_VALUE, _handle); > + > + EXPECT_EQ(DEFAULT_VALUE, result); > +} > + > +TEST(vector_restore_signal_handler_override) > +{ > + int result; > + > + result = vector_sigreturn(DEFAULT_VALUE, _override); > + > + EXPECT_EQ(SIGNAL_HANDLER_OVERRIDE, result); > +} > + > +TEST_HARNESS_MAIN > > --- > base-commit: 4cece764965020c22cff7665b18a012006359095 > change-id: 20240403-vector_sigreturn_tests-8118f0ac54fa

Re: [PATCH bpf-next] selftests/bpf: Add F_SETFL for fcntl

Hi Jakub, On Wed, 2024-04-03 at 15:29 -0700, John Fastabend wrote: > Jakub Sitnicki wrote: > > Hi Geliang, > > > > On Wed, Apr 03, 2024 at 04:32 PM +08, Geliang Tang wrote: > > > From: Geliang Tang > > > > > > Incorrect arguments are passed to fcntl() in test_sockmap.c when > > > invoking > >

[PATCH] riscv: selftests: Add signal handling vector tests

_sigreturn(DEFAULT_VALUE, _handle); + + EXPECT_EQ(DEFAULT_VALUE, result); +} + +TEST(vector_restore_signal_handler_override) +{ + int result; + + result = vector_sigreturn(DEFAULT_VALUE, _override); + + EXPECT_EQ(SIGNAL_HANDLER_OVERRIDE, result); +} + +TEST_HARNESS_MAIN

[PATCH v3 29/29] kselftest/riscv: kselftest for user mode cfi

Adds kselftest for RISC-V control flow integrity implementation for user mode. There is not a lot going on in kernel for enabling landing pad for user mode. cfi selftest are intended to be compiled with zicfilp and zicfiss enabled compiler. Thus kselftest simply checks if landing pad and shadow

[PATCH v3 28/29] riscv: Documentation for shadow stack on riscv

Adding documentation on shadow stack for user mode on riscv and kernel interfaces exposed so that user tasks can enable it. Signed-off-by: Deepak Gupta --- Documentation/arch/riscv/zicfiss.rst | 169 +++ 1 file changed, 169 insertions(+) create mode 100644

[PATCH v3 27/29] riscv: Documentation for landing pad / indirect branch tracking

Adding documentation on landing pad aka indirect branch tracking on riscv and kernel interfaces exposed so that user tasks can enable it. Signed-off-by: Deepak Gupta --- Documentation/arch/riscv/zicfilp.rst | 104 +++ 1 file changed, 104 insertions(+) create mode 100644

[PATCH v3 26/29] riscv: create a config for shadow stack and landing pad instr support

This patch creates a config for shadow stack support and landing pad instr support. Shadow stack support and landing instr support can be enabled by selecting `CONFIG_RISCV_USER_CFI`. Selecting `CONFIG_RISCV_USER_CFI` wires up path to enumerate CPU support and if cpu support exists, kernel will

[PATCH v3 25/29] riscv/hwprobe: zicfilp / zicfiss enumeration in hwprobe

Adding enumeration of zicfilp and zicfiss extensions in hwprobe syscall. Signed-off-by: Deepak Gupta --- arch/riscv/include/uapi/asm/hwprobe.h | 2 ++ arch/riscv/kernel/sys_hwprobe.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/riscv/include/uapi/asm/hwprobe.h

[PATCH v3 24/29] riscv/ptrace: riscv cfi status and state via ptrace and in core files

Expose a new register type NT_RISCV_USER_CFI for risc-v cfi status and state. Intentionally both landing pad and shadow stack status and state are rolled into cfi state. Creating two different NT_RISCV_USER_XXX would not be useful and wastage of a note type. Enabling or disabling of feature is not

[PATCH v3 23/29] riscv signal: Save and restore of shadow stack for signal

Save shadow stack pointer in sigcontext structure while delivering signal. Restore shadow stack pointer from sigcontext on sigreturn. As part of save operation, kernel uses `ssamoswap` to save snapshot of current shadow stack on shadow stack itself (can be called as a save token). During restore

[PATCH v3 22/29] riscv sigcontext: adding cfi state field in sigcontext

Shadow stack needs to be saved and restored on signal delivery and signal return. sigcontext embedded in ucontext is extendible. Adding cfi state in there which can be used to save cfi state before signal delivery and restore cfi state on sigreturn Signed-off-by: Deepak Gupta ---

[PATCH v3 21/29] riscv/traps: Introduce software check exception

zicfiss / zicfilp introduces a new exception to priv isa `software check exception` with cause code = 18. This patch implements software check exception. Additionally it implements a cfi violation handler which checks for code in xtval. If xtval=2, it means that sw check exception happened

[PATCH v3 20/29] riscv/kernel: update __show_regs to print shadow stack register

Updating __show_regs to print captured shadow stack pointer as well. On tasks where shadow stack is disabled, it'll simply print 0. Signed-off-by: Deepak Gupta --- arch/riscv/kernel/process.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/riscv/kernel/process.c

[PATCH v3 19/29] riscv: Implements arch agnostic indirect branch tracking prctls

prctls implemented are: PR_SET_INDIR_BR_LP_STATUS, PR_GET_INDIR_BR_LP_STATUS and PR_LOCK_INDIR_BR_LP_STATUS. Signed-off-by: Deepak Gupta --- arch/riscv/include/asm/usercfi.h | 22 - arch/riscv/kernel/process.c | 5 +++ arch/riscv/kernel/usercfi.c | 76

[PATCH v3 18/29] riscv: Implements arch agnostic shadow stack prctls

Implement architecture agnostic prctls() interface for setting and getting shadow stack status. prctls implemented are PR_GET_SHADOW_STACK_STATUS, PR_SET_SHADOW_STACK_STATUS and PR_LOCK_SHADOW_STACK_STATUS. As part of PR_SET_SHADOW_STACK_STATUS/PR_GET_SHADOW_STACK_STATUS, only

[PATCH v3 17/29] prctl: arch-agnostic prctl for indirect branch tracking

Three architectures (x86, aarch64, riscv) have support for indirect branch tracking feature in a very similar fashion. On a very high level, indirect branch tracking is a CPU feature where CPU tracks branches which uses memory operand to perform control transfer in program. As part of this

[PATCH v3 16/29] prctl: arch-agnostic prctl for shadow stack

From: Mark Brown Three architectures (x86, aarch64, riscv) have announced support for shadow stacks with fairly similar functionality. While x86 is using arch_prctl() to control the functionality neither arm64 nor riscv uses that interface so this patch adds arch-agnostic prctl() support to get

[PATCH v3 15/29] riscv/shstk: If needed allocate a new shadow stack on clone

Userspace specifies VM_CLONE to share address space and spawn new thread. `clone` allow userspace to specify a new stack for new thread. However there is no way to specify new shadow stack base address without changing API. This patch allocates a new shadow stack whenever VM_CLONE is given. In

[PATCH v3 14/29] riscv/mm: Implement map_shadow_stack() syscall

As discussed extensively in the changelog for the addition of this syscall on x86 ("x86/shstk: Introduce map_shadow_stack syscall") the existing mmap() and madvise() syscalls do not map entirely well onto the security requirements for shadow stack memory since they lead to windows where memory is

[PATCH v3 13/29] riscv mmu: write protect and shadow stack

`fork` implements copy on write (COW) by making pages readonly in child and parent both. ptep_set_wrprotect and pte_wrprotect clears _PAGE_WRITE in PTE. Assumption is that page is readable and on fault copy on write happens. To implement COW on such pages, clearing up W bit makes them XWR = 000.

[PATCH v3 12/29] riscv mmu: teach pte_mkwrite to manufacture shadow stack PTEs

pte_mkwrite creates PTEs with WRITE encodings for underlying arch. Underlying arch can have two types of writeable mappings. One that can be written using regular store instructions. Another one that can only be written using specialized store instructions (like shadow stack stores). pte_mkwrite

[PATCH v3 11/29] riscv mm: manufacture shadow stack pte

This patch implements creating shadow stack pte (on riscv). Creating shadow stack PTE on riscv means that clearing RWX and then setting W=1. Signed-off-by: Deepak Gupta --- arch/riscv/include/asm/pgtable.h | 12 1 file changed, 12 insertions(+) diff --git

[PATCH v3 10/29] riscv/mm : ensure PROT_WRITE leads to VM_READ | VM_WRITE

`arch_calc_vm_prot_bits` is implemented on risc-v to return VM_READ | VM_WRITE if PROT_WRITE is specified. Similarly `riscv_sys_mmap` is updated to convert all incoming PROT_WRITE to (PROT_WRITE | PROT_READ). This is to make sure that any existing apps using PROT_WRITE still work. Earlier

[PATCH v3 09/29] mm: abstract shadow stack vma behind `vma_is_shadow_stack`

VM_SHADOW_STACK (alias to VM_HIGH_ARCH_5) to encode shadow stack VMA. This patch changes checks of VM_SHADOW_STACK flag in generic code to call to a function `vma_is_shadow_stack` which will return true if its a shadow stack vma and default stub (when support doesnt exist) returns false.

[PATCH v3 08/29] mm: Define VM_SHADOW_STACK for RISC-V

VM_SHADOW_STACK is defined by x86 as vm flag to mark a shadow stack vma. x86 uses VM_HIGH_ARCH_5 bit but that limits shadow stack vma to 64bit only. arm64 follows same path (see links) To keep things simple, RISC-V follows the same. This patch adds `ss` for shadow stack in process maps. Links:

[PATCH v3 07/29] riscv: usercfi state for task and save/restore of CSR_SSP on trap entry/exit

Carves out space in arch specific thread struct for cfi status and shadow stack in usermode on riscv. This patch does following - defines a new structure cfi_status with status bit for cfi feature - defines shadow stack pointer, base and size in cfi_status structure - defines offsets to new

[PATCH v3 06/29] riscv: zicfiss / zicfilp extension csr and bit definitions

zicfiss and zicfilp extension gets enabled via b3 and b2 in *envcfg CSR. menvcfg controls enabling for S/HS mode. henvcfg control enabling for VS while senvcfg controls enabling for U/VU mode. zicfilp extension extends *status CSR to hold `expected landing pad` bit. A trap or interrupt can occur

[PATCH v3 05/29] riscv: zicfiss / zicfilp enumeration

This patch adds support for detecting zicfiss and zicfilp. zicfiss and zicfilp stands for unprivleged integer spec extension for shadow stack and branch tracking on indirect branches, respectively. This patch looks for zicfiss and zicfilp in device tree and accordinlgy lights up bit in cpu

[PATCH v3 04/29] riscv: zicfilp / zicfiss in dt-bindings (extensions.yaml)

Make an entry for cfi extensions in extensions.yaml. Signed-off-by: Deepak Gupta --- .../devicetree/bindings/riscv/extensions.yaml | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml

[PATCH v3 03/29] riscv/Kconfig: enable HAVE_EXIT_THREAD for riscv

riscv will need an implementation for exit_thread to clean up shadow stack when thread exits. If current thread had shadow stack enabled, shadow stack is allocated by default for any new thread. Signed-off-by: Deepak Gupta --- arch/riscv/Kconfig | 1 + arch/riscv/kernel/process.c | 5

[PATCH v3 02/29] riscv: define default value for envcfg for task

Defines a base default value for envcfg per task. By default all tasks should have cache zeroing capability. Any future base capabilities that apply to all tasks can be turned on same way. Signed-off-by: Deepak Gupta --- arch/riscv/include/asm/csr.h | 2 ++ arch/riscv/kernel/process.c | 6

[PATCH v3 01/29] riscv: envcfg save and restore on task switching

envcfg CSR defines enabling bits for cache management instructions and soon will control enabling for control flow integrity and pointer masking features. Control flow integrity enabling for forward cfi and backward cfi are controlled via envcfg and thus need to be enabled on per thread basis.

[PATCH v3 00/29] riscv control-flow integrity for usermode

Sending out v3 for cpu assisted riscv user mode control flow integrity. v2 [9] was sent a week ago for this riscv usermode control flow integrity enabling. RFC patchset was (v1) early this year (January) [7]. changes in v3 -- envcfg: logic to pick up base envcfg had a bug where

Re: [PATCH bpf-next] selftests/bpf: Add F_SETFL for fcntl

Jakub Sitnicki wrote: > Hi Geliang, > > On Wed, Apr 03, 2024 at 04:32 PM +08, Geliang Tang wrote: > > From: Geliang Tang > > > > Incorrect arguments are passed to fcntl() in test_sockmap.c when invoking > > it to set file status flags. If O_NONBLOCK is used as 2nd argument and > > passed into

Re: [PATCH v6 1/2] posix-timers: Prefer delivery of signals to the current thread

On Wed, Apr 03 2024 at 12:35, John Stultz wrote: > On Wed, Apr 3, 2024 at 12:10 PM Thomas Gleixner wrote: >> >> On Wed, Apr 03 2024 at 11:16, John Stultz wrote: >> > On Wed, Apr 3, 2024 at 9:32 AM Thomas Gleixner wrote: >> > Thanks for this, Thomas! >> > >> > Just FYI: testing with 6.1, the test

Re: [PATCH v2] Documentation: kunit: Clarify test filter format

On Tue, Apr 2, 2024 at 5:51 AM Brendan Jackman wrote: > > It seems obvious once you know, but at first I didn't realise that the > suite name is part of this format. Document it and add some examples. > > Signed-off-by: Brendan Jackman Reviewed-by: Daniel Latypov Thanks! I agree with your

Re: [PATCH net-next 7/7] testing: net-drv: add a driver test for stats reporting

On Wed, 3 Apr 2024 18:52:50 +0200 Petr Machata wrote: > > Nothing wrong with that. I guess the question in my mind is whether > > we're aiming for making the tests "pythonic" (in which case "with" > > definitely wins), or more of a "bash with classes" style trying to > > avoid any constructs

[KTAP V2 PATCH v4] ktap_v2: add test metadata

Add specification for test metadata to the KTAP v2 spec. KTAP v1 only specifies the output format of very basic test information: test result and test name. Any additional test information either gets added to general diagnostic data or is not included in the output at all. The purpose of KTAP

Re: [PATCH v3 00/15] Add support for suppressing warning backtraces

On Wed, Apr 03, 2024 at 06:19:21AM -0700, Guenter Roeck wrote: > Some unit tests intentionally trigger warning backtraces by passing bad > parameters to kernel API functions. Such unit tests typically check the > return value from such calls, not the existence of the warning backtrace. > > Such

Re: [PATCH] selftests: cgroup: skip test_cgcore_lesser_ns_open when cgroup2 mounted without nsdelegate

On Wed, Mar 27, 2024 at 10:44:37AM +0800, Tianchen Ding wrote: > The test case test_cgcore_lesser_ns_open only tasks effect when cgroup2 > is mounted with "nsdelegate" mount option. If it misses this option, or > is remounted without "nsdelegate", the test case will fail. For example, > running

Re: [PATCH v6 1/2] posix-timers: Prefer delivery of signals to the current thread

On Wed, Apr 3, 2024 at 12:10 PM Thomas Gleixner wrote: > > On Wed, Apr 03 2024 at 11:16, John Stultz wrote: > > On Wed, Apr 3, 2024 at 9:32 AM Thomas Gleixner wrote: > > Thanks for this, Thomas! > > > > Just FYI: testing with 6.1, the test no longer hangs, but I don't see > > the SKIP behavior.

Re: [PATCH v6 1/2] posix-timers: Prefer delivery of signals to the current thread

On Wed, Apr 03 2024 at 11:16, John Stultz wrote: > On Wed, Apr 3, 2024 at 9:32 AM Thomas Gleixner wrote: > Thanks for this, Thomas! > > Just FYI: testing with 6.1, the test no longer hangs, but I don't see > the SKIP behavior. It just fails: > not ok 6 check signal distribution > # Totals: pass:5

Re: [PATCH bpf-next v5 1/6] bpf/helpers: introduce sleepable bpf_timers

On Wed, Mar 27, 2024 at 10:02 AM Benjamin Tissoires wrote: > > > goto out; > > > } > > > + spin_lock(>sleepable_lock); > > > drop_prog_refcnt(t); > > > + spin_unlock(>sleepable_lock); > > > > this also looks odd. > > I basically need to protect "t->prog

Re: [PATCH v1 2/2] RISC-V: drop SOC_VIRT for ARCH_VIRT

On Tue, 05 Mar 2024 10:37:06 PST (-0800), Conor Dooley wrote: From: Conor Dooley The ARCH_ and SOC_ versions of this symbol have persisted for quite a while now in parallel. Generated .config files from previous LTS kernels should have both. Finally remove SOC_VIRT and update all config files

Re: [PATCH v6 1/2] posix-timers: Prefer delivery of signals to the current thread

On Wed, Apr 3, 2024 at 9:32 AM Thomas Gleixner wrote: > Subject: selftests/timers/posix_timers: Make signal distribution test less > fragile > From: Thomas Gleixner > > The signal distribution test has a tendency to hang for a long time as the > signal delivery is not really evenly distributed.

Re: [RFC PATCH net-next v8 06/14] page_pool: convert to use netmem

On Tue, Apr 02, 2024 at 05:20:43PM -0700, Mina Almasry wrote: > Abstrace the memory type from the page_pool so we can later add support > for new memory types. Convert the page_pool to use the new netmem type > abstraction, rather than use struct page directly. > > As of this patch the netmem

Re: [PATCH net-next 7/7] testing: net-drv: add a driver test for stats reporting

Jakub Kicinski writes: > On Wed, 3 Apr 2024 10:58:19 +0200 Petr Machata wrote: >> Also, it's not clear what "del thing" should do in that context, because >> if cfg also keeps a reference, __del__ won't get called. There could be >> a direct method, like thing.exit() or whatever, but then you

Re: [PATCH v2] KVM: selftests: Fix build error due to assert in dirty_log_test

On Wed, Apr 03, 2024, Raghavendra Rao Ananta wrote: > The commit e5ed6c922537 ("KVM: selftests: Fix a semaphore imbalance in > the dirty ring logging test") backported the fix from v6.8 to stable > v6.1. However, since the patch uses 'TEST_ASSERT_EQ()', which doesn't > exist on v6.1, the following

[PATCH v2] KVM: selftests: Fix build error due to assert in dirty_log_test

The commit e5ed6c922537 ("KVM: selftests: Fix a semaphore imbalance in the dirty ring logging test") backported the fix from v6.8 to stable v6.1. However, since the patch uses 'TEST_ASSERT_EQ()', which doesn't exist on v6.1, the following build error is seen: dirty_log_test.c:775:2: error: call

Re: Subject: [PATCH] Add test for more file systems in landlock - ext4

On Tue, Apr 02, 2024 at 01:37:44PM +0530, Saasha Gupta wrote: > Date: Mon, 2 Apr 2024 19:59:56 +0530 > > RE: This patch is now properly preformatted. > > Landlock LSM, a part of the security subsystem, has some tests in place > for synthetic filesystems such as tmpfs, proc, sysfs, etc. The goal

[PATCH] KVM: selftests: Fix build error due to assert in dirty_log_test

The commit e5ed6c922537 ("KVM: selftests: Fix a semaphore imbalance in the dirty ring logging test") backported the fix from v6.8 to stable v6.1. However, since the patch uses 'TEST_ASSERT_EQ()', which doesn't exist on v6.1, the following build error is seen: dirty_log_test.c:775:2: error: call

Re: [PATCH v6 1/2] posix-timers: Prefer delivery of signals to the current thread

On Wed, Apr 03 2024 at 17:43, Thomas Gleixner wrote: > On Wed, Apr 03 2024 at 17:03, Oleg Nesterov wrote: >> >> Why distribution_thread() can't simply exit if got_signal != 0 ? >> >> See https://lore.kernel.org/all/20230128195641.ga14...@redhat.com/ > > Indeed. It's too obvious :) Revised simpler

Re: [PATCH 1/2] cgroup/cpuset: Make cpuset hotplug processing synchronous

On 03/04/24 10:47, Waiman Long wrote: > On 4/3/24 10:26, Valentin Schneider wrote: >> IIUC that was Thomas' suggestion [1], but I can't tell yet how bad it would >> be to change cgroup_lock() to also do a cpus_read_lock(). > > Changing the locking order is certainly doable. I have taken a cursory

Re: Re: [PATCH 1/2] cgroup/cpuset: Make cpuset hotplug processing synchronous

On 03/04/24 16:54, Michal Koutný wrote: > On Wed, Apr 03, 2024 at 04:26:38PM +0200, Valentin Schneider > wrote: >> Also, I gave Michal's patch a try and it looks like it's introducing a > > Thank you. > >> cgroup_threadgroup_rwsem -> cpuset_mutex >> ordering from >>

Re: [PATCH v6 1/2] posix-timers: Prefer delivery of signals to the current thread

On Wed, Apr 03 2024 at 17:03, Oleg Nesterov wrote: > On 04/03, Thomas Gleixner wrote: >> The test if fragile as hell as there is absolutely no guarantee that the >> signal target distribution is as expected. The expectation is based on a >> statistical assumption which does not really hold. > >

Re: [PATCH 1/2] cgroup/cpuset: Make cpuset hotplug processing synchronous

On 4/3/24 10:56, Michal Koutný wrote: On Wed, Apr 03, 2024 at 10:47:33AM -0400, Waiman Long wrote: should be rare these days as it will only apply in the case of cgroup v1 under certain condtion, Could the migration be simply omitted it those special cases? (Tasks remain in cpusets with

Re: [PATCH v6 1/2] posix-timers: Prefer delivery of signals to the current thread

On 04/03, Thomas Gleixner wrote: > > The test if fragile as hell as there is absolutely no guarantee that the > signal target distribution is as expected. The expectation is based on a > statistical assumption which does not really hold. Agreed. I too never liked this test-case. I forgot

Re: Re: [PATCH 1/2] cgroup/cpuset: Make cpuset hotplug processing synchronous

On Wed, Apr 03, 2024 at 10:47:33AM -0400, Waiman Long wrote: > should be rare these days as it will only apply in the case of cgroup > v1 under certain condtion, Could the migration be simply omitted it those special cases? (Tasks remain in cpusets with empty cpusets -- that already happens in

Re: Re: [PATCH 1/2] cgroup/cpuset: Make cpuset hotplug processing synchronous

On Wed, Apr 03, 2024 at 04:26:38PM +0200, Valentin Schneider wrote: > Also, I gave Michal's patch a try and it looks like it's introducing a Thank you. > cgroup_threadgroup_rwsem -> cpuset_mutex > ordering from > cgroup_transfer_tasks_locked() > `\ >

Re: [PATCH 1/2] cgroup/cpuset: Make cpuset hotplug processing synchronous

On 4/3/24 10:26, Valentin Schneider wrote: On 03/04/24 09:38, Waiman Long wrote: On 4/3/24 08:02, Michal Koutný wrote: On Tue, Apr 02, 2024 at 11:30:11AM -0400, Waiman Long wrote: Yes, there is a potential that a cpus_read_lock() may be called leading to deadlock. So unless we reverse the

Re: [PATCH 1/2] cgroup/cpuset: Make cpuset hotplug processing synchronous

On 03/04/24 09:38, Waiman Long wrote: > On 4/3/24 08:02, Michal Koutný wrote: >> On Tue, Apr 02, 2024 at 11:30:11AM -0400, Waiman Long >> wrote: >>> Yes, there is a potential that a cpus_read_lock() may be called leading to >>> deadlock. So unless we reverse the current cgroup_mutex -->

Re: [PATCH net-next 7/7] testing: net-drv: add a driver test for stats reporting

On Wed, 3 Apr 2024 10:58:19 +0200 Petr Machata wrote: > Also, it's not clear what "del thing" should do in that context, because > if cfg also keeps a reference, __del__ won't get called. There could be > a direct method, like thing.exit() or whatever, but then you need > bookkeeping so as not to

Re: [PATCH 1/2] cgroup/cpuset: Make cpuset hotplug processing synchronous

On 4/3/24 08:02, Michal Koutný wrote: On Tue, Apr 02, 2024 at 11:30:11AM -0400, Waiman Long wrote: Yes, there is a potential that a cpus_read_lock() may be called leading to deadlock. So unless we reverse the current cgroup_mutex --> cpu_hotplug_lock ordering, it is not safe to call

[PATCH v3 15/15] powerpc: Add support for suppressing warning backtraces

Add name of functions triggering warning backtraces to the __bug_table object section to enable support for suppressing WARNING backtraces. To limit image size impact, the pointer to the function name is only added to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and

[PATCH v3 14/15] riscv: Add support for suppressing warning backtraces

Add name of functions triggering warning backtraces to the __bug_table object section to enable support for suppressing WARNING backtraces. To limit image size impact, the pointer to the function name is only added to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and

[PATCH v3 13/15] sh: Move defines needed for suppressing warning backtraces

Declaring the defines needed for suppressing warning inside '#ifdef CONFIG_DEBUG_BUGVERBOSE' results in a kerneldoc warning. .../bug.h:29: warning: expecting prototype for _EMIT_BUG_ENTRY(). Prototype was for HAVE_BUG_FUNCTION() instead Move the defines above the kerneldoc entry for

[PATCH v3 12/15] sh: Add support for suppressing warning backtraces

Add name of functions triggering warning backtraces to the __bug_table object section to enable support for suppressing WARNING backtraces. To limit image size impact, the pointer to the function name is only added to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and

[PATCH v3 11/15] s390: Add support for suppressing warning backtraces

Add name of functions triggering warning backtraces to the __bug_table object section to enable support for suppressing WARNING backtraces. To limit image size impact, the pointer to the function name is only added to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and

[PATCH v3 10/15] parisc: Add support for suppressing warning backtraces

Add name of functions triggering warning backtraces to the __bug_table object section to enable support for suppressing WARNING backtraces. To limit image size impact, the pointer to the function name is only added to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and

[PATCH v3 09/15] loongarch: Add support for suppressing warning backtraces

Add name of functions triggering warning backtraces to the __bug_table object section to enable support for suppressing WARNING backtraces. To limit image size impact, the pointer to the function name is only added to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and

[PATCH v3 08/15] arm64: Add support for suppressing warning backtraces

Add name of functions triggering warning backtraces to the __bug_table object section to enable support for suppressing WARNING backtraces. To limit image size impact, the pointer to the function name is only added to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and

[PATCH v3 07/15] x86: Add support for suppressing warning backtraces

Add name of functions triggering warning backtraces to the __bug_table object section to enable support for suppressing WARNING backtraces. To limit image size impact, the pointer to the function name is only added to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and

[PATCH v3 06/15] net: kunit: Suppress lock warning noise at end of dev_addr_lists tests

dev_addr_lists_test generates lock warning noise at the end of tests if lock debugging is enabled. There are two sets of warnings. WARNING: CPU: 0 PID: 689 at kernel/locking/mutex.c:923 __mutex_unlock_slowpath.constprop.0+0x13c/0x368 DEBUG_LOCKS_WARN_ON(__owner_task(owner) != __get_current())

[PATCH v3 05/15] drm: Suppress intentional warning backtraces in scaling unit tests

The drm_test_rect_calc_hscale and drm_test_rect_calc_vscale unit tests intentionally trigger warning backtraces by providing bad parameters to the tested functions. What is tested is the return value, not the existence of a warning backtrace. Suppress the backtraces to avoid clogging the kernel

[PATCH v3 04/15] kunit: Add documentation for warning backtrace suppression API

Document API functions for suppressing warning backtraces. Tested-by: Linux Kernel Functional Testing Acked-by: Dan Carpenter Reviewed-by: Kees Cook Signed-off-by: Guenter Roeck --- v2: - Rebased to v6.9-rc1 - Added Tested-by:, Acked-by:, and Reviewed-by: tags v3: - Rebased to v6.9-rc2

[PATCH v3 03/15] kunit: Add test cases for backtrace warning suppression

Add unit tests to verify that warning backtrace suppression works. If backtrace suppression does _not_ work, the unit tests will likely trigger unsuppressed backtraces, which should actually help to get the affected architectures / platforms fixed. Tested-by: Linux Kernel Functional Testing

[PATCH v3 02/15] kunit: bug: Count suppressed warning backtraces

Count suppressed warning backtraces to enable code which suppresses warning backtraces to check if the expected backtrace(s) have been observed. Using atomics for the backtrace count resulted in build errors on some architectures due to include file recursion, so use a plain integer for now.

[PATCH v3 01/15] bug/kunit: Core support for suppressing warning backtraces

Some unit tests intentionally trigger warning backtraces by passing bad parameters to API functions. Such unit tests typically check the return value from those calls, not the existence of the warning backtrace. Such intentionally generated warning backtraces are neither desirable nor useful for

[PATCH v3 00/15] Add support for suppressing warning backtraces

Some unit tests intentionally trigger warning backtraces by passing bad parameters to kernel API functions. Such unit tests typically check the return value from such calls, not the existence of the warning backtrace. Such intentionally generated warning backtraces are neither desirable nor

Re: [PATCH v6 1/2] posix-timers: Prefer delivery of signals to the current thread

On Tue, Apr 02 2024 at 10:23, John Stultz wrote: > On Tue, Apr 2, 2024 at 7:57 AM Thomas Gleixner wrote: >> This test in particular exercises new functionality/behaviour, which >> really has no business to be backported into stable just to make the >> relevant test usable on older kernels. > >

Re: [PATCH bpf-next] selftests/bpf: Add F_SETFL for fcntl

Hi Geliang, On Wed, Apr 03, 2024 at 04:32 PM +08, Geliang Tang wrote: > From: Geliang Tang > > Incorrect arguments are passed to fcntl() in test_sockmap.c when invoking > it to set file status flags. If O_NONBLOCK is used as 2nd argument and > passed into fcntl, -EINVAL will be returned (See

Re: [PATCH bpf-next v3] selftests/bpf: Move test_dev_cgroup to prog_tests

On 4/3/24 7:36 AM, Yonghong Song wrote: > > On 4/2/24 8:16 AM, Muhammad Usama Anjum wrote: >> Yonghong Song, >> >> Thank you so much for replying. I was missing how to run pipeline manually. >> Thanks a ton. >> >> On 4/1/24 11:53 PM, Yonghong Song wrote: >>> On 4/1/24 5:34 AM, Muhammad Usama

Re: Re: [PATCH 1/2] cgroup/cpuset: Make cpuset hotplug processing synchronous

On Tue, Apr 02, 2024 at 11:30:11AM -0400, Waiman Long wrote: > Yes, there is a potential that a cpus_read_lock() may be called leading to > deadlock. So unless we reverse the current cgroup_mutex --> cpu_hotplug_lock > ordering, it is not safe to call cgroup_transfer_tasks() directly. I see

Re: [PATCH net-next 7/7] testing: net-drv: add a driver test for stats reporting

Jakub Kicinski writes: > On Wed, 3 Apr 2024 00:04:14 +0200 Petr Machata wrote: >> > Yes, I was wondering about that. It must be doable, IIRC >> > the multi-threading API "injects" args from a tuple. >> > I was thinking something along the lines of: >> > >> > with NetDrvEnv(__file__) as

[PATCH bpf-next] selftests/bpf: Add F_SETFL for fcntl

From: Geliang Tang Incorrect arguments are passed to fcntl() in test_sockmap.c when invoking it to set file status flags. If O_NONBLOCK is used as 2nd argument and passed into fcntl, -EINVAL will be returned (See do_fcntl() in fs/fcntl.c). The correct approach is to use F_SETFL as 2nd argument,

[PATCH v5 22/22] KVM: riscv: selftests: Add a test for counter overflow

Add a test for verifying overflow interrupt. Currently, it relies on overflow support on cycle/instret events. This test works for cycle/ instret events which support sampling via hpmcounters on the platform. There are no ISA extensions to detect if a platform supports that. Thus, this test will

[PATCH v5 21/22] KVM: riscv: selftests: Add a test for PMU snapshot functionality

Verify PMU snapshot functionality by setting up the shared memory correctly and reading the counter values from the shared memory instead of the CSR. Reviewed-by: Anup Patel Signed-off-by: Atish Patra --- .../testing/selftests/kvm/include/riscv/sbi.h | 25

[PATCH v5 20/22] KVM: riscv: selftests: Add SBI PMU selftest

This test implements basic sanity test and cycle/instret event counting tests. Reviewed-by: Anup Patel Signed-off-by: Atish Patra --- tools/testing/selftests/kvm/Makefile | 1 + .../selftests/kvm/riscv/sbi_pmu_test.c| 340 ++ 2 files changed, 341

[PATCH v5 19/22] KVM: riscv: selftests: Add SBI PMU extension definitions

The SBI PMU extension definition is required for upcoming SBI PMU selftests. Reviewed-by: Anup Patel Signed-off-by: Atish Patra --- .../testing/selftests/kvm/include/riscv/sbi.h | 66 +++ 1 file changed, 66 insertions(+) diff --git

[PATCH v5 18/22] KVM: riscv: selftests: Add Sscofpmf to get-reg-list test

The KVM RISC-V allows Sscofpmf extension for Guest/VM so let us add this extension to get-reg-list test. Reviewed-by: Anup Patel Reviewed-by: Andrew Jones Signed-off-by: Atish Patra --- tools/testing/selftests/kvm/riscv/get-reg-list.c | 4 1 file changed, 4 insertions(+) diff --git

[PATCH v5 17/22] KVM: riscv: selftests: Add helper functions for extension checks

__vcpu_has_ext can check both SBI and ISA extensions when the first argument is properly converted to SBI/ISA extension IDs. Introduce two helper functions to make life easier for developers so they don't have to worry about the conversions. Replace the current usages as well with new helpers.

[PATCH v5 16/22] KVM: riscv: selftests: Move sbi definitions to its own header file

The SBI definitions will continue to grow. Move the sbi related definitions to its own header file from processor.h Suggested-by: Andrew Jones Signed-off-by: Atish Patra --- .../selftests/kvm/include/riscv/processor.h | 39 --- .../testing/selftests/kvm/include/riscv/sbi.h | 50

[PATCH v5 15/22] RISC-V: KVM: Improve firmware counter read function

Rename the function to indicate that it is meant for firmware counter read. While at it, add a range sanity check for it as well. Signed-off-by: Atish Patra --- arch/riscv/include/asm/kvm_vcpu_pmu.h | 2 +- arch/riscv/kvm/vcpu_pmu.c | 7 ++- arch/riscv/kvm/vcpu_sbi_pmu.c

[PATCH v5 14/22] RISC-V: KVM: Support 64 bit firmware counters on RV32

The SBI v2.0 introduced a fw_read_hi function to read 64 bit firmware counters for RV32 based systems. Add infrastructure to support that. Reviewed-by: Anup Patel Signed-off-by: Atish Patra --- arch/riscv/include/asm/kvm_vcpu_pmu.h | 4 ++- arch/riscv/kvm/vcpu_pmu.c | 44

  1   2   >