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
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);
>
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
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
>
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);
> > > > +
\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
>
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
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
> >
_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
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
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
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
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
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
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
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
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
---
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
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
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
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
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
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
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
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
`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.
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
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
`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
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.
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:
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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.
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
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
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
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.
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
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
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
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
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
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
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
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
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
>>
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.
>
>
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
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
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
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()
> `\
>
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
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 -->
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
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
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
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
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
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
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
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
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
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
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
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())
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
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
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
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.
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
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
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.
>
>
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
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
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
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
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,
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
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
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
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
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
__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.
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
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
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 - 100 of 115 matches
Mail list logo