On Thu, Mar 28, 2024 at 9:46 PM Deepak Gupta wrote:
>
> 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
>
> >
> > +- const: zicfilp
> > + description:
> > +The standard Zicfilp extension for enforcing forward edge
> > control-flow
> > +integrity as ratified in commit 0036ff2 of riscv-cfi.
> > +
> > +- const: zicfiss
> > + description:
> > +
On Fri, Mar 29, 2024, at 12:44 AM, Deepak Gupta wrote:
> Adds description in dt-bindings (extensions.yaml)
>
> 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,
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. Thus kselftest simply enables landing pad for the binary and
a signal handler is registered for SIGSEGV. Any control flow violation are
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
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
x86 has used VM_SHADOW_STACK (alias to VM_HIGH_ARCH_5) to encode shadow
stack VMA. VM_SHADOW_STACK is thus not possible on 32bit. Some arches may
need a way to encode shadow stack on 32bit and 64bit both and they may
encode this information differently in VMAs.
This patch changes checks of
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
https://lore.kernel.org/lkml/20231009-arm64-gcs-v6-12-78e55deaa...@kernel.org/#r
To keep things simple, RISC-V follows the
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
Adds description in dt-bindings (extensions.yaml)
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
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 | 1 +
2
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 is controlled
via envcfg and thus need to be enabled on per thread basis.
I had sent RFC patchset early this year (January) [7] to enable CPU assisted
control-flow integrity for usermode on riscv. Since then I've been able to do
more testing of the changes. As part of testing effort, compiled a rootfs with
shadow stack and landing pad enabled (libraries and binaries)
Hello,
kernel test robot noticed "kernel-selftests.pidfd.pidfd_setns_test.fail" on:
commit: 0710a1a73fb45033ebb06073e374ab7d44a05f15 ("selftests/harness: Merge
TEST_F_FORK() into TEST_F()")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
[test failed on linus/master
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Tue, 26 Mar 2024 17:54:27 +0100 you wrote:
> As discussed on the bi-weekly call on Jan 30, and in mailing around
> kernel CI effort, some changes are desirable in the suite of forwarding
> selftests the better to
Hello:
This patch was applied to netdev/net.git (main)
by Andrew Morton :
On Mon, 25 Mar 2024 19:40:52 + you wrote:
> Following issue was observed while running the uffd-unit-tests selftest
> on ARM devices. On x86_64 no issues were detected:
>
> pthread_create followed by fork caused
This patch series introduces a new char misc driver, /dev/ntsync, which is used
to implement Windows NT synchronization primitives.
== Background ==
The Wine project emulates the Windows API in user space. One particular part of
that API, namely the NT synchronization primitives, have
ntsync uses a misc device as the simplest and least intrusive uAPI interface.
Each file description on the device represents an isolated NT instance, intended
to correspond to a single NT virtual machine.
Signed-off-by: Elizabeth Figura
---
drivers/misc/Kconfig | 11 +
NT waits can optionally be made "alertable". This is a special channel for
thread wakeup that is mildly similar to SIGIO. A thread has an internal single
bit of "alerted" state, and if a thread is alerted while an alertable wait, the
wait will return a special value, consume the "alerted" state,
This corresponds to the NT syscall NtQuerySemaphore().
This returns the current count and maximum count of the semaphore.
Signed-off-by: Elizabeth Figura
---
drivers/misc/ntsync.c | 21 +
include/uapi/linux/ntsync.h | 1 +
2 files changed, 22 insertions(+)
diff
This corresponds to the NT syscall NtQueryMutant().
This returns the recursion count, owner, and abandoned state of the mutex.
Signed-off-by: Elizabeth Figura
---
drivers/misc/ntsync.c | 23 +++
include/uapi/linux/ntsync.h | 1 +
2 files changed, 24 insertions(+)
This corresponds to the NT syscall NtQueryEvent().
This returns the signaled state of the event and whether it is manual-reset.
Signed-off-by: Elizabeth Figura
---
drivers/misc/ntsync.c | 21 +
include/uapi/linux/ntsync.h | 1 +
2 files changed, 22 insertions(+)
Test the "alert" functionality of NTSYNC_IOC_WAIT_ALL and NTSYNC_IOC_WAIT_ANY,
when a wait is woken with an alert and when it is woken by an object.
Signed-off-by: Elizabeth Figura
---
.../testing/selftests/drivers/ntsync/ntsync.c | 179 +-
1 file changed, 176 insertions(+), 3
This corresponds to the NT syscall NtCreateMutant().
An NT mutex is recursive, with a 32-bit recursion counter. When acquired via
NtWaitForMultipleObjects(), the recursion counter is incremented by one.
The OS records the thread which acquired it. However, in order to keep this
driver
This corresponds to the NT syscall NtCreateSemaphore().
Semaphores are one of three types of object to be implemented in this driver,
the others being mutexes and events.
An NT semaphore contains a 32-bit counter, and is signaled and can be acquired
when the counter is nonzero. The counter has a
This corresponds to part of the functionality of the NT syscall
NtWaitForMultipleObjects(). Specifically, it implements the behaviour where
the third argument (wait_any) is TRUE, and it does not handle alertable waits.
Those features have been split out into separate patches to ease review.
This corresponds to the NT syscall NtReleaseSemaphore().
This increases the semaphore's internal counter by the given value, and returns
the previous value. If the counter would overflow the defined maximum, the
function instead fails and returns -EOVERFLOW.
Signed-off-by: Elizabeth Figura
---
This is similar to NTSYNC_IOC_WAIT_ANY, but waits until all of the objects are
simultaneously signaled, and then acquires all of them as a single atomic
operation.
Signed-off-by: Elizabeth Figura
---
drivers/misc/ntsync.c | 243 ++--
Test contended "wait-for-all" waits, to make sure that scheduling and wakeup
logic works correctly, and that the wait only exits once objects are all
simultaneously signaled.
Signed-off-by: Elizabeth Figura
---
.../testing/selftests/drivers/ntsync/ntsync.c | 98 +++
1 file
Test event-specific ioctls NTSYNC_IOC_EVENT_SET, NTSYNC_IOC_EVENT_RESET,
NTSYNC_IOC_EVENT_PULSE, NTSYNC_IOC_EVENT_READ for manual-reset events, and
waiting on manual-reset events.
Signed-off-by: Elizabeth Figura
---
.../testing/selftests/drivers/ntsync/ntsync.c | 89 +++
1 file
Test basic synchronous functionality of NTSYNC_IOC_WAIT_ALL, and when objects
are considered simultaneously signaled.
Signed-off-by: Elizabeth Figura
---
.../testing/selftests/drivers/ntsync/ntsync.c | 99 ++-
1 file changed, 97 insertions(+), 2 deletions(-)
diff --git
Test contended "wait-for-any" waits, to make sure that scheduling and wakeup
logic works correctly.
Signed-off-by: Elizabeth Figura
---
.../testing/selftests/drivers/ntsync/ntsync.c | 150 ++
1 file changed, 150 insertions(+)
diff --git
This corresponds to the NT syscall NtPulseEvent().
This wakes up any waiters as if the event had been set, but does not set the
event, instead resetting it if it had been signalled. Thus, for a manual-reset
event, all waiters are woken, whereas for an auto-reset event, at most one
waiter is
This corresponds to the NT syscall NtSetEvent().
This sets the event to the signaled state, and returns its previous state.
Signed-off-by: Elizabeth Figura
---
drivers/misc/ntsync.c | 37 +
include/uapi/linux/ntsync.h | 1 +
2 files changed, 38
This correspond to the NT syscall NtCreateEvent().
An NT event holds a single bit of state denoting whether it is signaled or
unsignaled.
There are two types of events: manual-reset and automatic-reset. When an
automatic-reset event is acquired via a wait function, its state is reset to
This does not correspond to any NT syscall. Rather, when a thread dies, it
should be called by the NT emulator for each mutex.
NT mutexes are robust (in the pthread sense). When an NT thread dies, any
mutexes it owned are immediately released. Acquisition of those mutexes by other
threads will
This corresponds to the NT syscall NtResetEvent().
This sets the event to the unsignaled state, and returns its previous state.
Signed-off-by: Elizabeth Figura
---
drivers/misc/ntsync.c | 22 ++
include/uapi/linux/ntsync.h | 1 +
2 files changed, 23 insertions(+)
This corresponds to the NT syscall NtReleaseMutant().
This syscall decrements the mutex's recursion count by one, and returns the
previous value. If the mutex is not owned by the given owner ID, the function
instead fails and returns -EPERM.
Signed-off-by: Elizabeth Figura
---
Expand the contended wait tests, which previously only covered events and
semaphores, to cover events as well.
Signed-off-by: Elizabeth Figura
---
.../testing/selftests/drivers/ntsync/ntsync.c | 151 +-
1 file changed, 147 insertions(+), 4 deletions(-)
diff --git
Test event-specific ioctls NTSYNC_IOC_EVENT_SET, NTSYNC_IOC_EVENT_RESET,
NTSYNC_IOC_EVENT_PULSE, NTSYNC_IOC_EVENT_READ for auto-reset events, and
waiting on auto-reset events.
Signed-off-by: Elizabeth Figura
---
.../testing/selftests/drivers/ntsync/ntsync.c | 59 +++
1 file
Test mutex-specific ioctls NTSYNC_IOC_MUTEX_UNLOCK and NTSYNC_IOC_MUTEX_READ,
and waiting on mutexes.
Signed-off-by: Elizabeth Figura
---
.../testing/selftests/drivers/ntsync/ntsync.c | 196 ++
1 file changed, 196 insertions(+)
diff --git
Wine has tests for its synchronization primitives, but these are more accessible
to kernel developers, and also allow us to test some edge cases that Wine does
not care about.
This patch adds tests for semaphore-specific ioctls NTSYNC_IOC_SEM_POST and
NTSYNC_IOC_SEM_READ, and waiting on
Test basic synchronous functionality of NTSYNC_IOC_WAIT_ANY, when objects are
considered signaled or not signaled, and how they are affected by a successful
wait.
Signed-off-by: Elizabeth Figura
---
.../testing/selftests/drivers/ntsync/ntsync.c | 119 ++
1 file changed, 119
FEAT_FPMR defines a new register FMPR which is available at all ELs and is
discovered via ID_AA64PFR2_EL1.FPMR, add this to the set of registers that
get-reg-list knows to check for with the required identification register
depdendency.
Signed-off-by: Mark Brown
---
The 2023 architecture extensions allocated some previously usused feature
registers, add comments mapping the names in get-reg-list as we do for the
other allocated registers.
Signed-off-by: Mark Brown
---
tools/testing/selftests/kvm/aarch64/get-reg-list.c | 4 ++--
1 file changed, 2
FEAT_FPMR introduces a new system register FPMR which allows configuration
of floating point behaviour, currently for FP8 specific features. Allow use
of this in guests, disabling the trap while guests are running and saving
and restoring the value along with the rest of the floating point state
The 2023 architecture extensions have allocated some new ID registers, add
them to the KVM system register descriptions so that they are visible to
guests.
We make the newly introduced dpISA features writeable, as well as
allowing writes to ID_AA64ISAR3_EL1.CPA for FEAT_CPA which only
introduces
As part of the lazy FPSIMD state transitioning done by the hypervisor we
currently share the userpsace FPSIMD state in thread->uw.fpsimd_state with
the host. Since this struct is non-extensible userspace ABI we have to keep
the definition as is but the addition of FPMR in the 2023 dpISA means that
This series implements support for the 2023 dpISA extensions in KVM
guests, it was previously posted as part of a series with the host
support but that has now been merged so only the KVM portions remain.
Most of these extensions add only new instructions so the guest support
consists of adding
Add an overall explanation of the driver architecture, and complete and precise
specification for its intended behaviour.
Signed-off-by: Elizabeth Figura
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/ntsync.rst | 399 +
2 files changed,
Add myself as maintainer, supported by CodeWeavers.
Signed-off-by: Elizabeth Figura
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index aa3b947fb080..84d03d95f44b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15720,6 +15720,15 @@ T:
Test a more realistic usage pattern, and one with heavy contention, in order to
actually exercise ntsync's internal synchronization.
This test has several threads in a tight loop acquiring a mutex, modifying some
shared data, and then releasing the mutex. At the end we check if the data is
Expand the alert tests to cover alerting a thread mid-wait, to test that the
relevant scheduling logic works correctly.
Signed-off-by: Elizabeth Figura
---
.../testing/selftests/drivers/ntsync/ntsync.c | 62 +++
1 file changed, 62 insertions(+)
diff --git
Hello,
On Thu, Mar 28, 2024 at 02:28:51PM -0700, Alexei Starovoitov wrote:
> > > So filename will be one of cgroup_base_files[].name ?
> > > We probably don't want psi or cgroup1_base_files in there.
> >
> > Would it matter?
>
> Few weak reasons:
> . cgroup_psi_files have show/write/poll/release
On Thu, Mar 28, 2024 at 8:10 AM Steven Rostedt wrote:
>
> On Thu, 28 Mar 2024 22:43:46 +0800
> 梦龙董 wrote:
>
> > I have done a simple benchmark on creating 1000
> > trampolines. It is slow, quite slow, which consume up to
> > 60s. We can't do it this way.
> >
> > Now, I have a bad idea. How about
On Thu, 2024-03-28 at 14:08 -0600, Shuah Khan wrote:
> On 3/26/24 04:09, David Gow wrote:
> > On Tue, 26 Mar 2024 at 15:55, Johannes Berg
> > wrote:
> > >
> > > On Tue, 2024-03-26 at 01:52 +, Jakub Kicinski wrote:
> > > >
> > > > I'm late to the party, but FWIW I had to toss this into
On Thu, Mar 28, 2024 at 2:01 PM Tejun Heo wrote:
>
> Hello,
>
> On Thu, Mar 28, 2024 at 01:45:56PM -0700, Alexei Starovoitov wrote:
> > On Thu, Mar 28, 2024 at 1:02 PM Tejun Heo wrote:
> > >
> > > There's also cgroup.kill which would be useful for similar use cases. We
> > > can
> > > add
Hello,
On Thu, Mar 28, 2024 at 01:45:56PM -0700, Alexei Starovoitov wrote:
> On Thu, Mar 28, 2024 at 1:02 PM Tejun Heo wrote:
> >
> > There's also cgroup.kill which would be useful for similar use cases. We can
> > add interface for both but idk. Let's say we have something like the
> >
On Thu, Mar 28, 2024 at 1:02 PM Tejun Heo wrote:
>
> There's also cgroup.kill which would be useful for similar use cases. We can
> add interface for both but idk. Let's say we have something like the
> following (pardon the bad naming):
>
> bpf_cgroup_knob_write(struct cgroup *cgrp, char
On Thu, Mar 28, 2024 at 11:55:23AM -0700, Mina Almasry wrote:
> On Thu, Mar 28, 2024 at 11:28 AM Simon Horman wrote:
> >
> > On Tue, Mar 26, 2024 at 03:50:35PM -0700, Mina Almasry wrote:
> > > Add a netdev_dmabuf_binding struct which represents the
> > > dma-buf-to-netdevice binding. The netlink
Hi Shuah,
On 3/28/2024 12:25 PM, Shuah Khan wrote:
> On 3/27/24 17:08, Reinette Chatre wrote:
>> On 2/27/2024 8:36 AM, Reinette Chatre wrote:
>>> Could you please consider this series for inclusion? I do admit that
>>> there has been a lot of resctrl selftest work recently. This should be
>>> it
On 3/26/24 04:09, David Gow wrote:
On Tue, 26 Mar 2024 at 15:55, Johannes Berg wrote:
On Tue, 2024-03-26 at 01:52 +, Jakub Kicinski wrote:
I'm late to the party, but FWIW I had to toss this into netdev testing
tree as a local patch:
CONFIG_NETDEVICES=y
CONFIG_WLAN=y
I'll send this in
Hello,
On Thu, Mar 28, 2024 at 12:46:03PM -0700, Alexei Starovoitov wrote:
> To use kernel_file_open() it would need path, inode, cred.
Yeah, it's more involved and potentially more controversial. That said, just
to push the argument a bit further, at least for path, it'd be nice to have
a
On Thu, Mar 28, 2024 at 10:58 AM Tejun Heo wrote:
>
> Hello, Alexei.
>
> On Thu, Mar 28, 2024 at 10:32:24AM -0700, Alexei Starovoitov wrote:
> > > It bothers me a bit that it's adding a dedicated interface for something
> > > which already has a defined userspace interface. Would it be better to
On 3/27/24 17:08, Reinette Chatre wrote:
Hi Shuah,
On 2/27/2024 8:36 AM, Reinette Chatre wrote:
Hi Shuah,
Could you please consider this series for inclusion? I do admit that
there has been a lot of resctrl selftest work recently. This should be
it for a while as new work is still being
On Thu, Mar 28, 2024 at 11:28 AM Simon Horman wrote:
>
> On Tue, Mar 26, 2024 at 03:50:35PM -0700, Mina Almasry wrote:
> > Add a netdev_dmabuf_binding struct which represents the
> > dma-buf-to-netdevice binding. The netlink API will bind the dma-buf to
> > rx queues on the netdevice. On the
On 3/27/24 05:17, Muhammad Usama Anjum wrote:
Skip instead of failing when prerequisite conditions aren't fulfilled,
such as invalid xstate values etc. This patch would make the tests show
as skip when run by:
make -C tools/testing/selftests/ TARGETS=x86 run_tests
...
# timeout set to
On 3/27/24 12:46, Muhammad Usama Anjum wrote:
There are multiple #ifdef blocks inside functions where they return just
0 if #ifdef is false. This makes number of tests counting difficult.
Move those functions inside one #ifdef block and move all of them
together. This is preparatory patch for
On Tue, Mar 26, 2024 at 03:50:35PM -0700, Mina Almasry wrote:
> Add a netdev_dmabuf_binding struct which represents the
> dma-buf-to-netdevice binding. The netlink API will bind the dma-buf to
> rx queues on the netdevice. On the binding, the dma_buf_attach
> & dma_buf_map_attachment will occur.
On Thu, Mar 28, 2024 at 7:20 AM 'Brendan Jackman' via KUnit
Development 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 example.
>
> Signed-off-by: Brendan Jackman
> ---
>
Hello, Alexei.
On Thu, Mar 28, 2024 at 10:32:24AM -0700, Alexei Starovoitov wrote:
> > It bothers me a bit that it's adding a dedicated interface for something
> > which already has a defined userspace interface. Would it be better to have
> > kfunc wrappers for kernel_read() and kernel_write()?
On Thu, Mar 28, 2024 at 10:22 AM Tejun Heo wrote:
>
> Hello, Djalal.
>
> On Wed, Mar 27, 2024 at 11:53:22PM +0100, Djalal Harouni wrote:
> > This patch series adds support to freeze the task cgroup hierarchy
> > that is on a default cgroup v2 without going through kernfs interface.
> >
> > For
On 3/28/24 2:02 AM, Muhammad Usama Anjum wrote:
On 3/28/24 8:34 AM, John Hubbard wrote:
Hi,
As mentioned in each patch, this implements the solution that we discussed in
December 2023, in [1]. This turned out to be very clean and easy. It should also
be quite easy to maintain.
There is
Hello, Djalal.
On Wed, Mar 27, 2024 at 11:53:22PM +0100, Djalal Harouni wrote:
> This patch series adds support to freeze the task cgroup hierarchy
> that is on a default cgroup v2 without going through kernfs interface.
>
> For some cases we want to freeze the cgroup of a task based on some
>
On Thu, 28 Mar 2024 22:43:46 +0800
梦龙董 wrote:
> I have done a simple benchmark on creating 1000
> trampolines. It is slow, quite slow, which consume up to
> 60s. We can't do it this way.
>
> Now, I have a bad idea. How about we introduce
> a "dynamic trampoline"? The basic logic of it can be:
>
On Fri, Mar 15, 2024 at 4:00 PM 梦龙董 wrote:
>
> On Thu, Mar 14, 2024 at 8:27 AM Alexei Starovoitov
> wrote:
> >
> > On Tue, Mar 12, 2024 at 6:53 PM 梦龙董 wrote:
> [..]
> > > What does "a hundred attachments max" means? Can't I
> > > trace thousands of kernel functions with a bpf program of
> >
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 example.
Signed-off-by: Brendan Jackman
---
Documentation/dev-tools/kunit/run_wrapper.rst | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git
On 27/03/2024 20:04, Mirsad Todorovac wrote:
> On 3/27/24 11:41, Joao Martins wrote:
>> On 25/03/2024 13:52, Jason Gunthorpe wrote:
>>> On Mon, Mar 25, 2024 at 12:17:28PM +, Joao Martins wrote:
> However, I am not smart enough to figure out why ...
>
> Apparently, from the source,
Hi Andrew,
Thank you for reviewing my patches.
On 3/27/2024 4:57 PM, Andrew Jones wrote:
> On Wed, Mar 27, 2024 at 05:42:54AM +, Manali Shukla wrote:
> ...
>> diff --git a/tools/testing/selftests/kvm/include/kvm_util_base.h
>> b/tools/testing/selftests/kvm/include/kvm_util_base.h
>> index
On 3/28/24 8:34 AM, John Hubbard wrote:
> Hi,
>
> As mentioned in each patch, this implements the solution that we discussed in
> December 2023, in [1]. This turned out to be very clean and easy. It should
> also
> be quite easy to maintain.
There is another way. The headers should be built
On Tue, Mar 26, 2024 at 01:19:20PM -0700, Mina Almasry wrote:
>
> Are you envisioning that dmabuf support would be added to the block
> layer
Yes.
> (which I understand is part of the VFS and not driver specific),
The block layer isn't really the VFS, it's just another core stack
like the
99 matches
Mail list logo
