Re: [PATCH v4 08/15] RISC-V: KVM: Implement SBI PMU Snapshot feature

2024-04-03 Thread Atish Patra
On 4/1/24 15:36, Atish Patra wrote: On Sat, Mar 2, 2024 at 1:49 AM Andrew Jones wrote: On Wed, Feb 28, 2024 at 05:01:23PM -0800, Atish Patra wrote: PMU Snapshot function allows to minimize the number of traps when the guest access configures/access the hpmcounters. If the snapshot feature is

[PATCH v5 00/22] RISC-V SBI v2.0 PMU improvements and Perf sampling in KVM guest

2024-04-03 Thread Atish Patra
This series implements SBI PMU improvements done in SBI v2.0[1] i.e. PMU snapshot and fw_read_hi() functions. SBI v2.0 introduced PMU snapshot feature which allows the SBI implementation to provide counter information (i.e. values/overflow status) via a shared memory between the SBI implementati

[PATCH v5 01/22] RISC-V: Fix the typo in Scountovf CSR name

2024-04-03 Thread Atish Patra
The counter overflow CSR name is "scountovf" not "sscountovf". Fix the csr name. Fixes: 4905ec2fb7e6 ("RISC-V: Add sscofpmf extension support") Reviewed-by: Clément Léger Reviewed-by: Conor Dooley Reviewed-by: Anup Patel Signed-off-by: Atish Patra --- arch/riscv/include/asm/csr.h | 2 +- dri

[PATCH v5 02/22] RISC-V: Add FIRMWARE_READ_HI definition

2024-04-03 Thread Atish Patra
SBI v2.0 added another function to SBI PMU extension to read the upper bits of a counter with width larger than XLEN. Add the definition for that function. Reviewed-by: Clément Léger Acked-by: Conor Dooley Reviewed-by: Anup Patel Signed-off-by: Atish Patra --- arch/riscv/include/asm/sbi.h |

[PATCH v5 03/22] drivers/perf: riscv: Read upper bits of a firmware counter

2024-04-03 Thread Atish Patra
SBI v2.0 introduced a explicit function to read the upper 32 bits for any firmware counter width that is longer than 32bits. This is only applicable for RV32 where firmware counter can be 64 bit. Reviewed-by: Andrew Jones Acked-by: Palmer Dabbelt Reviewed-by: Conor Dooley Reviewed-by: Anup Pate

[PATCH v5 04/22] drivers/perf: riscv: Use BIT macro for shifting operations

2024-04-03 Thread Atish Patra
It is a good practice to use BIT() instead of (1UL << x). Replace the current usages with BIT(). Signed-off-by: Atish Patra --- arch/riscv/include/asm/sbi.h | 20 ++-- drivers/perf/riscv_pmu_sbi.c | 2 +- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/arch/risc

[PATCH v5 05/22] RISC-V: Add SBI PMU snapshot definitions

2024-04-03 Thread Atish Patra
SBI PMU Snapshot function optimizes the number of traps to higher privilege mode by leveraging a shared memory between the S/VS-mode and the M/HS mode. Add the definitions for that extension and new error codes. Reviewed-by: Anup Patel Acked-by: Palmer Dabbelt Signed-off-by: Atish Patra --- ar

[PATCH v5 06/22] drivers/perf: riscv: Implement SBI PMU snapshot function

2024-04-03 Thread Atish Patra
SBI v2.0 SBI introduced PMU snapshot feature which adds the following features. 1. Read counter values directly from the shared memory instead of csr read. 2. Start multiple counters with initial values with one SBI call. These functionalities optimizes the number of traps to the higher privilege

[PATCH v5 07/22] drivers/perf: riscv: Fix counter mask iteration for RV32

2024-04-03 Thread Atish Patra
For RV32, used_hw_ctrs can have more than 1 word if the firmware chooses to interleave firmware/hardware counters indicies. Even though it's a unlikely scenario, handle that case by iterating over all the words instead of just using the first word. Signed-off-by: Atish Patra --- drivers/perf/ris

[PATCH v5 08/22] RISC-V: KVM: Fix the initial sample period value

2024-04-03 Thread Atish Patra
The initial sample period value when counter value is not assigned should be set to maximum value supported by the counter width. Otherwise, it may result in spurious interrupts. Signed-off-by: Atish Patra --- arch/riscv/kvm/vcpu_pmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH v5 09/22] RISC-V: KVM: Rename the SBI_STA_SHMEM_DISABLE to a generic name

2024-04-03 Thread Atish Patra
SBI_STA_SHMEM_DISABLE is a macro to invoke disable shared memory commands. As this can be invoked from other SBI extension context as well, rename it to more generic name as SBI_SHMEM_DISABLE. Signed-off-by: Atish Patra --- arch/riscv/include/asm/sbi.h | 2 +- arch/riscv/kernel/paravirt.c | 6

[PATCH v5 10/22] RISC-V: KVM: No need to update the counter value during reset

2024-04-03 Thread Atish Patra
The virtual counter value is updated during pmu_ctr_read. There is no need to update it in reset case. Otherwise, it will be counted twice which is incorrect. Fixes: 0cb74b65d2e5 ("RISC-V: KVM: Implement perf support without sampling") Reviewed-by: Anup Patel Reviewed-by: Andrew Jones Signed-off

[PATCH v5 11/22] RISC-V: KVM: No need to exit to the user space if perf event failed

2024-04-03 Thread Atish Patra
Currently, we return a linux error code if creating a perf event failed in kvm. That shouldn't be necessary as guest can continue to operate without perf profiling or profiling with firmware counters. Return appropriate SBI error code to indicate that PMU configuration failed. An error message in

[PATCH v5 12/22] RISC-V: KVM: Implement SBI PMU Snapshot feature

2024-04-03 Thread Atish Patra
PMU Snapshot function allows to minimize the number of traps when the guest access configures/access the hpmcounters. If the snapshot feature is enabled, the hypervisor updates the shared memory with counter data and state of overflown counters. The guest can just read the shared memory instead of

[PATCH v5 13/22] RISC-V: KVM: Add perf sampling support for guests

2024-04-03 Thread Atish Patra
KVM enables perf for guest via counter virtualization. However, the sampling can not be supported as there is no mechanism to enabled trap/emulate scountovf in ISA yet. Rely on the SBI PMU snapshot to provide the counter overflow data via the shared memory. In case of sampling event, the host firs

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

2024-04-03 Thread Atish Patra
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 +

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

2024-04-03 Thread Atish Patra
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 16/22] KVM: riscv: selftests: Move sbi definitions to its own header file

2024-04-03 Thread Atish Patra
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 17/22] KVM: riscv: selftests: Add helper functions for extension checks

2024-04-03 Thread Atish Patra
__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. Si

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

2024-04-03 Thread Atish Patra
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 a/too

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

2024-04-03 Thread Atish Patra
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 a/tools/testing/selftests/kvm/include/riscv/sb

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

2024-04-03 Thread Atish Patra
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 insertions(+)

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

2024-04-03 Thread Atish Patra
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 .../selftests/kvm/lib/riscv/proc

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

2024-04-03 Thread Atish Patra
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 fa

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

2024-04-03 Thread Geliang Tang
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, a

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

2024-04-03 Thread Petr Machata
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 cfg

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

2024-04-03 Thread Michal Koutný
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 that

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

2024-04-03 Thread Muhammad Usama Anjum
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 Anjum

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

2024-04-03 Thread Jakub Sitnicki
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 do_f

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

2024-04-03 Thread Thomas Gleixner
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. > > Tha

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

2024-04-03 Thread Guenter Roeck
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 useful

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

2024-04-03 Thread Guenter Roeck
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 a

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

2024-04-03 Thread Guenter Roeck
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. Acke

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

2024-04-03 Thread Guenter Roeck
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 Acke

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

2024-04-03 Thread Guenter Roeck
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 Docum

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

2024-04-03 Thread Guenter Roeck
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 log

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

2024-04-03 Thread Guenter Roeck
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()) WA

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

2024-04-03 Thread Guenter Roeck
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 CONFIG_DEBUG

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

2024-04-03 Thread Guenter Roeck
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 CONFIG_DEBUG

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

2024-04-03 Thread Guenter Roeck
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 CONFIG_DEBUG

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

2024-04-03 Thread Guenter Roeck
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 CONFIG_DEBUG

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

2024-04-03 Thread Guenter Roeck
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 CONFIG_DEBUG

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

2024-04-03 Thread Guenter Roeck
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 CONFIG_DEBUG

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

2024-04-03 Thread Guenter Roeck
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 _EMIT

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

2024-04-03 Thread Guenter Roeck
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 CONFIG_DEBUG

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

2024-04-03 Thread Guenter Roeck
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 CONFIG_DEBUG

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

2024-04-03 Thread Waiman Long
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 cgroup_tra

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

2024-04-03 Thread Jakub Kicinski
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 c

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

2024-04-03 Thread Valentin Schneider
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 --> cpu_hotpl

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

2024-04-03 Thread Waiman Long
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 cu

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

2024-04-03 Thread Michal Koutný
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() > `\ > percpu_down_write(&cgroup_threadgr

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

2024-04-03 Thread Michal Koutný
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: [PATCH v6 1/2] posix-timers: Prefer delivery of signals to the current thread

2024-04-03 Thread Oleg Nesterov
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 everythi

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

2024-04-03 Thread Waiman Long
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 em

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

2024-04-03 Thread Thomas Gleixner
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. > > Agr

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

2024-04-03 Thread Valentin Schneider
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 >> cgroup_transfer_tasks_lock

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

2024-04-03 Thread Valentin Schneider
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: [PATCH v6 1/2] posix-timers: Prefer delivery of signals to the current thread

2024-04-03 Thread Thomas Gleixner
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

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

2024-04-03 Thread Raghavendra Rao Ananta
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 to

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

2024-04-03 Thread Mickaël Salaün
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 o

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

2024-04-03 Thread Raghavendra Rao Ananta
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 to

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

2024-04-03 Thread Sean Christopherson
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

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

2024-04-03 Thread Petr Machata
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 n

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

2024-04-03 Thread Simon Horman
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 type

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

2024-04-03 Thread John Stultz
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: [PATCH v1 2/2] RISC-V: drop SOC_VIRT for ARCH_VIRT

2024-04-03 Thread Palmer Dabbelt
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 u

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

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

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

2024-04-03 Thread Thomas Gleixner
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 v6 1/2] posix-timers: Prefer delivery of signals to the current thread

2024-04-03 Thread John Stultz
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. I

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

2024-04-03 Thread Tejun Heo
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 bpf

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

2024-04-03 Thread Kees Cook
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 in

[KTAP V2 PATCH v4] ktap_v2: add test metadata

2024-04-03 Thread Rae Moar
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 me

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

2024-04-03 Thread Jakub Kicinski
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 people

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

2024-04-03 Thread Daniel Latypov
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 com

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

2024-04-03 Thread Thomas Gleixner
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 bpf-next] selftests/bpf: Add F_SETFL for fcntl

2024-04-03 Thread John Fastabend
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 fcn

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

2024-04-03 Thread Deepak Gupta
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 `ENVCF

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

2024-04-03 Thread Deepak Gupta
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. Th

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

2024-04-03 Thread Deepak Gupta
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 03/29] riscv/Kconfig: enable HAVE_EXIT_THREAD for riscv

2024-04-03 Thread Deepak Gupta
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 04/29] riscv: zicfilp / zicfiss in dt-bindings (extensions.yaml)

2024-04-03 Thread Deepak Gupta
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 b/Documentation/devicetree/bindings

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

2024-04-03 Thread Deepak Gupta
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 feature

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

2024-04-03 Thread Deepak Gupta
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 b

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

2024-04-03 Thread Deepak Gupta
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 member

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

2024-04-03 Thread Deepak Gupta
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: h

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

2024-04-03 Thread Deepak Gupta
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. Signed-o

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

2024-04-03 Thread Deepak Gupta
`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 `protect

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

2024-04-03 Thread Deepak Gupta
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 a/arch/riscv/include/asm/p

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

2024-04-03 Thread Deepak Gupta
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 ca

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

2024-04-03 Thread Deepak Gupta
`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 14/29] riscv/mm: Implement map_shadow_stack() syscall

2024-04-03 Thread Deepak Gupta
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 a

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

2024-04-03 Thread Deepak Gupta
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 cas

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

2024-04-03 Thread Deepak Gupta
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 17/29] prctl: arch-agnostic prctl for indirect branch tracking

2024-04-03 Thread Deepak Gupta
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 tracking

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

2024-04-03 Thread Deepak Gupta
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 PR_SHADOW_STACK_ENA

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

2024-04-03 Thread Deepak Gupta
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 20/29] riscv/kernel: update __show_regs to print shadow stack register

2024-04-03 Thread Deepak Gupta
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 b/ar

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

2024-04-03 Thread Deepak Gupta
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 because

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

2024-04-03 Thread Deepak Gupta
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 --- arch/riscv/inc

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

2024-04-03 Thread Deepak Gupta
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 o

  1   2   >