1. Add documentation for remoteproc core
2. Add userspace api documentation.
3. Add kernel driver api documentation.
Signed-off-by: anish kumar
---
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202410161444.jokmsogs-...@intel.com/
Documentation/remoteproc/co
In preparation of making the documentation
mainline. Remove the documentation from staging.
Signed-off-by: anish kumar
---
v2:
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202410161444.jokmsogs-...@intel.com/
Documentation/staging/remoteproc.rst | 359 -
On Tue, Oct 15, 2024, Oliver Upton wrote:
> On Sat, Oct 12, 2024 at 10:28:10AM +0100, David Woodhouse wrote:
> > I suspect the real answer here is that the individual tests here be
> > calling ksft_test_result_pass(), and the system_off2 one should call
> > ksft_test_result_skip() if it skips?
>
>
On 10/16/24 08:52, Jonathan Corbet wrote:
Dan Carpenter writes:
On Tue, Oct 15, 2024 at 04:32:27PM +0200, 'Marco Elver' via HUST OS Kernel
Contribution wrote:
On Tue, 15 Oct 2024 at 16:11, Dongliang Mu wrote:
On Tue, Oct 15, 2024 at 10:09 PM Haoyang Liu wrote:
fix a typo in dev-tools/k
Add testing for the pointer masking extensions exposed to KVM guests.
Reviewed-by: Anup Patel
Signed-off-by: Samuel Holland
---
(no changes since v2)
Changes in v2:
- New patch for v2
tools/testing/selftests/kvm/riscv/get-reg-list.c | 8
1 file changed, 8 insertions(+)
diff --git
The interface for controlling pointer masking in VS-mode is henvcfg.PMM,
which is part of the Ssnpm extension, even though pointer masking in
HS-mode is provided by the Smnpm extension. As a result, emulating Smnpm
in the guest requires (only) Ssnpm on the host.
The guest configures Smnpm through
Supm is a virtual ISA extension defined in the RISC-V Pointer Masking
specification, which indicates that pointer masking is available in
U-mode. It can be provided by either Smnpm or Ssnpm, depending on which
mode the kernel runs in. Userspace should not care about this
distinction, so export Supm
This test covers the behavior of the PR_SET_TAGGED_ADDR_CTRL and
PR_GET_TAGGED_ADDR_CTRL prctl() operations, their effects on the
userspace ABI, and their effects on the system call ABI.
Reviewed-by: Charlie Jenkins
Tested-by: Charlie Jenkins
Signed-off-by: Samuel Holland
---
Changes in v5:
-
This allows a tracer to control the ABI of the tracee, as on arm64.
Signed-off-by: Samuel Holland
---
(no changes since v1)
arch/riscv/kernel/ptrace.c | 42 ++
include/uapi/linux/elf.h | 1 +
2 files changed, 43 insertions(+)
diff --git a/arch/riscv/kern
When pointer masking is enabled for userspace, the kernel can accept
tagged pointers as arguments to some system calls. Allow this by
untagging the pointers in access_ok() and the uaccess routines. The
uaccess routines must peform untagging in software because U-mode and
S-mode have entirely separa
RISC-V supports pointer masking with a variable number of tag bits
(which is called "PMLEN" in the specification) and which is configured
at the next higher privilege level.
Wire up the PR_SET_TAGGED_ADDR_CTRL and PR_GET_TAGGED_ADDR_CTRL prctls
so userspace can request a lower bound on the number
Pointer masking is controlled via a two-bit PMM field, which appears in
various CSRs depending on which extensions are implemented. Smmpm adds
the field to mseccfg; Smnpm adds the field to menvcfg; Ssnpm adds the
field to senvcfg. If the H extension is implemented, Ssnpm also defines
henvcfg.PMM an
The RISC-V Pointer Masking specification defines three extensions:
Smmpm, Smnpm, and Ssnpm. Add support for parsing each of them. The
specific extension which provides pointer masking support to userspace
(Supm) depends on the kernel's privilege mode, so provide a macro to
abstract this selection.
RISC-V defines three extensions for pointer masking[1]:
- Smmpm: configured in M-mode, affects M-mode
- Smnpm: configured in M-mode, affects the next lower mode (S or U-mode)
- Ssnpm: configured in S-mode, affects the next lower mode (VS, VU, or U-mode)
This series adds support for configuring
The RISC-V Pointer Masking specification defines three extensions:
Smmpm, Smnpm, and Ssnpm. Document the behavior of these extensions as
following the ratified version 1.0 of the specification.
Acked-by: Conor Dooley
Reviewed-by: Charlie Jenkins
Signed-off-by: Samuel Holland
---
Changes in v5:
On 16.10.24 17:47, David Hildenbrand wrote:
When I wrote that code I was rather convinced that the variant in this patch
is the right thing to do.
A short explanation about what a stand-alone kdump is.
* First, it's not really a _regular_ kdump activated with kexec-tools and
executed by L
When I wrote that code I was rather convinced that the variant in this patch
is the right thing to do.
A short explanation about what a stand-alone kdump is.
* First, it's not really a _regular_ kdump activated with kexec-tools and
executed by Linux itself but a regular stand-alone dump (SC
Hi Anish,
First and foremost, there are kernel bot problems to fix.
On Mon, Oct 14, 2024 at 07:58:31PM -0700, anish kumar wrote:
> Add the documentation in the mainline from
> staging and add the relvant information from
> current mainline.
>
> Added:
> 1. userspace api documentation.
> 2. kerne
Dan Carpenter writes:
> On Tue, Oct 15, 2024 at 04:32:27PM +0200, 'Marco Elver' via HUST OS Kernel
> Contribution wrote:
>> On Tue, 15 Oct 2024 at 16:11, Dongliang Mu wrote:
>> >
>> > On Tue, Oct 15, 2024 at 10:09 PM Haoyang Liu
>> > wrote:
>> > >
>> > > fix a typo in dev-tools/kmsan.rst
>> >
Hi David,
> My concern is that we'll now have
>
> bool is_kdump_kernel(void)
> {
> return oldmem_data.start && !is_ipl_type_dump();
> }
>
> Which matches 3), but if 2) is also called "kdump", then should it actually
> be
>
> bool is_kdump_kernel(void)
> {
> return oldmem_data.sta
On Wed, Oct 16, 2024 at 3:30 PM Dan Carpenter wrote:
>
> On Tue, Oct 15, 2024 at 04:32:27PM +0200, 'Marco Elver' via HUST OS Kernel
> Contribution wrote:
> > On Tue, 15 Oct 2024 at 16:11, Dongliang Mu
> > wrote:
> > >
> > > On Tue, Oct 15, 2024 at 10:09 PM Haoyang Liu
> > > wrote:
> > > >
> >
On Tue, Oct 15, 2024 at 04:32:27PM +0200, 'Marco Elver' via HUST OS Kernel
Contribution wrote:
> On Tue, 15 Oct 2024 at 16:11, Dongliang Mu wrote:
> >
> > On Tue, Oct 15, 2024 at 10:09 PM Haoyang Liu
> > wrote:
> > >
> > > fix a typo in dev-tools/kmsan.rst
> > >
> > > Signed-off-by: Haoyang Liu
Since we've migrated all tests to the KUnit framework,
we can delete CONFIG_KASAN_MODULE_TEST and mentioning of it in the
documentation as well.
I've used the online translator to modify the non-English documentation.
Reviewed-by: Andrey Konovalov
Signed-off-by: Sabyrzhan Tasbolatov
---
Changes
Migrate the copy_user_test to the KUnit framework to verify out-of-bound
detection via KASAN reports in copy_from_user(), copy_to_user() and
their static functions.
This is the last migrated test in kasan_test_module.c, therefore delete
the file.
Reviewed-by: Andrey Konovalov
Signed-off-by: Saby
Since in the commit 2865baf54077("x86: support user address masking instead
of non-speculative conditional") do_strncpy_from_user() is called from
multiple places, we should sanitize the kernel *dst memory and size
which were done in strncpy_from_user() previously.
Fixes: 2865baf54077 ("x86: suppo
copy_user_test() is the last KUnit-incompatible test with
CONFIG_KASAN_MODULE_TEST requirement, which we are going to migrate to KUnit
framework and delete the former test and Kconfig as well.
In this patch series:
- [1/3] move kasan_check_write() and check_object_size() to
On Tue, 15 Oct 2024 11:01:44 -0400
Eric Farman wrote:
> > + [subcode] "i" (DIAG500_SC_STOR_LIMIT)
> > + : "memory", "1", "2");
> > + if (!storage_limit)
> > + return -EINVAL;
> > + /* Convert inclusive end to exclusive end */
> > + *max_physmem_end = storage_
el.org/pub/scm/linux/kernel/git/remoteproc/linux.git
rpmsg-next
patch link:
https://lore.kernel.org/r/20241015025831.65232-1-yesanishhere%40gmail.com
patch subject: [PATCH] remoteproc: Documentation: upgrade from staging.
reproduce:
(https://download.01.org/0day-ci/archive/20241016/20241016144
28 matches
Mail list logo
