On Thu, Oct 31 2024 at 14:10, Naresh Kamboju wrote:
> The QEMU-ARM64 boot has failed with the Linux next-20241031 tag.
> The boot log shows warnings at clockevents_register_device and followed
> by rcu_preempt detected stalls.
>
> However, the system did not proceed far enough to
The kernel has recently added support for shadow stacks, currently
x86 only using their CET feature but both arm64 and RISC-V have
equivalent features (GCS and Zicfiss respectively), I am actively
working on GCS[1]. With shadow stacks the hardware maintains an
additional stack containing only the
Currently as a result of templating from x86 code gcs_alloc_thread_stack()
returns a pointer as an unsigned int however on arm64 we don't actually use
this pointer value as anything other than a pass/fail flag. Simplify the
interface to just return an int with 0 on success and a negative error code
There are a number of architectures with shadow stack features which we are
presenting to userspace with as consistent an API as we can (though there
are some architecture specifics). Especially given that there are some
important considerations for userspace code interacting directly with the
feat
While almost all users of shadow stacks should be relying on the dynamic
linker and libc to enable the feature there are several low level test
programs where it is useful to enable without any libc support, allowing
testing without full system enablement. This low level testing is helpful
during b
In order to make it easier to add more configuration for the tests and
more support for runtime detection of when tests can be run pass the
structure describing the tests into test_clone3() rather than picking
the arguments out of it and have that function do all the per-test work.
No functional c
The clone_args structure is extensible, with the syscall passing in the
length of the structure. Inside the kernel we use copy_struct_from_user()
to read the struct but this has the unfortunate side effect of silently
accepting some overrun in the structure size providing the extra data is
all zero
Since there were widespread issues with output not being flushed the
kselftest framework was modified to explicitly set the output streams
unbuffered in commit 58e2847ad2e6 ("selftests: line buffer test
program's stdout") so there is no need to explicitly flush in the clone3
tests.
Reviewed-by: Ke
On 10/24/24 12:30, MD Danish Anwar wrote:
> @@ -183,9 +232,21 @@ trap cleanup_all_ns EXIT
> setup_hsr_interfaces 0
> do_complete_ping_test
>
> +# Run VLAN Test
> +if $vlan; then
> + setup_vlan_interfaces
> + hsr_vlan_ping
> +fi
> +
> setup_ns ns1 ns2 ns3
>
> setup_hsr_interfaces 1
>
On 10/31, Mina Almasry wrote:
> On Wed, Oct 30, 2024 at 8:37 AM Stanislav Fomichev
> wrote:
> >
> > On 10/30, Mina Almasry wrote:
> > > On Wed, Oct 30, 2024 at 8:13 AM Stanislav Fomichev
> > > wrote:
> > > >
> > > > On 10/30, Mina Almasry wrote:
> > > > > On Wed, Oct 30, 2024 at 7:27 AM Stanisl
On Thu, Oct 31, 2024 at 9:45 AM Mina Almasry wrote:
>
...
>
> Sorry, 2 issues testing this series:
>
...
>
> 2. Validation is now broken:
>
Validation is re-fixed with this diff:
diff --git a/tools/testing/selftests/drivers/net/hw/ncdevmem.c
b/tools/testing/selftests/drivers/net/hw/ncdevmem.c
in
Add basic test coverage for specifying the shadow stack for a newly
created thread via clone3(), including coverage of the newly extended
argument structure. We check that a user specified shadow stack can be
provided, and that invalid combinations of parameters are rejected.
In order to facilita
On Thu, 24 Oct 2024 10:59:53 +0100, Patrick Roy wrote:
> The loop in test_create_guest_memfd_invalid that is supposed to test
> that nothing is accepted as a valid flag to KVM_CREATE_GUEST_MEMFD was
> initializing `flag` as 0 instead of BIT(0). This caused the loop to
> immediately exit instead of
On Fri, 13 Sep 2024 13:43:15 +0800, Jiapeng Chong wrote:
> Use of macro ARRAY_SIZE to calculate array size minimizes
> the redundant code and improves code reusability.
>
> ./tools/testing/selftests/kvm/x86_64/debug_regs.c:169:32-33: WARNING: Use
> ARRAY_SIZE.
Applied to kvm-x86 selftests, thank
Hi Sean,
On 10/30/2024 12:57 PM, Sean Christopherson wrote:
> On Wed, Oct 30, 2024, Pratik R. Sampat wrote:
>> On 10/30/2024 8:46 AM, Sean Christopherson wrote:
>>> +/* Minimum firmware version required for the SEV-SNP support */
>>> +#define SNP_FW_REQ_VER_MAJOR 1
>>> +#define SNP_FW_REQ_VER_MI
On Wed, Oct 30, 2024 at 8:37 AM Stanislav Fomichev wrote:
>
> On 10/30, Mina Almasry wrote:
> > On Wed, Oct 30, 2024 at 8:13 AM Stanislav Fomichev
> > wrote:
> > >
> > > On 10/30, Mina Almasry wrote:
> > > > On Wed, Oct 30, 2024 at 7:27 AM Stanislav Fomichev
> > > > wrote:
> > > > >
> > > > >
2024-10-29, 11:47:25 +0100, Antonio Quartulli wrote:
> +static void ovpn_socket_release_work(struct work_struct *work)
> +{
> + struct ovpn_socket *sock = container_of(work, struct ovpn_socket, work);
> +
> + ovpn_socket_detach(sock->sock);
> + kfree_rcu(sock, rcu);
> +}
> +
> +static v
On 10/31/2024 09:16, Stefano Garzarella wrote:
On Tue, Oct 29, 2024 at 09:49:54AM -0500, Konstantin Shkolnyy wrote:
Change parameters of SO_VM_SOCKETS_* to uint64_t so that they are always
In include/uapi/linux/vm_sockets.h we talk about "unsigned long long",
but in the kernel code we use u64.
On Thu, Oct 31, 2024, Pratik R. Sampat wrote:
> Hi Sean,
>
> On 10/30/2024 12:57 PM, Sean Christopherson wrote:
> > On Wed, Oct 30, 2024, Pratik R. Sampat wrote:
> >> On 10/30/2024 8:46 AM, Sean Christopherson wrote:
> >>> +/* Minimum firmware version required for the SEV-SNP support */
> >>> +#de
On Wed, Oct 30, 2024 at 11:05:03PM +, Matthew Maurer wrote:
> diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
> index
> e6b2427e5c190aacf7b9c5c1bb57fca39d311564..a31c617cd67d3d66b24d2fba34cbd5cc9c53ab78
> 100644
> --- a/kernel/module/Kconfig
> +++ b/kernel/module/Kconfig
> @@ -208,
2024-10-29, 11:47:22 +0100, Antonio Quartulli wrote:
> +static int ovpn_udp_encap_recv(struct sock *sk, struct sk_buff *skb)
> +{
[...]
> + opcode = ovpn_opcode_from_skb(skb, sizeof(struct udphdr));
> + if (unlikely(opcode != OVPN_DATA_V2)) {
> + /* DATA_V1 is not supported */
>
On 10/25/24 09:30, Omid Ehtemam-Haghighi wrote:
> Soft lockups have been observed on a cluster of Linux-based edge routers
> located in a highly dynamic environment. Using the `bird` service, these
> routers continuously update BGP-advertised routes due to frequently
> changing nexthop destinations
On Thu, Oct 31 2024 at 10:56, Frederic Weisbecker wrote:
> On Thu, Oct 31, 2024 at 02:10:14PM +0530, Naresh Kamboju wrote:
>> <4>[ 0.220657] WARNING: CPU: 1 PID: 0 at kernel/time/clockevents.c:455
>> clockevents_register_device (kernel/time/clockevents.c:455
>
> It's possible that I messed up somet
On 31/10/2024 12:29, Sabrina Dubroca wrote:
2024-10-29, 11:47:22 +0100, Antonio Quartulli wrote:
+static int ovpn_udp_encap_recv(struct sock *sk, struct sk_buff *skb)
+{
[...]
+ opcode = ovpn_opcode_from_skb(skb, sizeof(struct udphdr));
+ if (unlikely(opcode != OVPN_DATA_V2)) {
+
On 31/10/2024 12:37, Sabrina Dubroca wrote:
2024-10-29, 11:47:24 +0100, Antonio Quartulli wrote:
@@ -136,6 +139,10 @@ void ovpn_decrypt_post(void *data, int ret)
goto drop;
}
+ /* increment RX stats */
+ ovpn_peer_stats_increment_rx(&peer->vpn_stats, skb->len
On Tue, Oct 29, 2024 at 09:49:54AM -0500, Konstantin Shkolnyy wrote:
Change parameters of SO_VM_SOCKETS_* to uint64_t so that they are always
In include/uapi/linux/vm_sockets.h we talk about "unsigned long long",
but in the kernel code we use u64. IIUC "unsigned long long" should be
u64 on eve
On 10/31/24 4:13 AM, Paolo Abeni wrote:
> Given the issue is long-standing, and the fix is somewhat invasive, I
> suggest steering this patch on net-next.
>
FWIW, I think net-next is best.
2024-10-29, 11:47:24 +0100, Antonio Quartulli wrote:
> @@ -136,6 +139,10 @@ void ovpn_decrypt_post(void *data, int ret)
> goto drop;
> }
>
> + /* increment RX stats */
> + ovpn_peer_stats_increment_rx(&peer->vpn_stats, skb->len);
> + ovpn_peer_stats_increment_rx(&p
On 29/10/2024 11:47, Antonio Quartulli wrote:
[...]
+
+ /* DATA_V2 packets are handled in kernel, the rest goes to user space */
+ if (likely(ovpn_opcode_from_skb(skb, 0) == OVPN_DATA_V2)) {
+ /* hold reference to peer as required by ovpn_recv().
+*
+
On 10/24/24 12:30, MD Danish Anwar wrote:
> From: Murali Karicheri
>
> This patch adds support for VLAN ctag based filtering at slave devices.
> The slave ethernet device may be capable of filtering ethernet packets
> based on VLAN ID. This requires that when the VLAN interface is created
> ov
This series was originally written by José Expósito, and has been
modified and updated by Matt Gilbride and myself. The original version
can be found here:
https://github.com/Rust-for-Linux/linux/pull/950
Add support for writing KUnit tests in Rust. While Rust doctests are
already converted to KUn
On Wed, 30 Oct 2024 at 13:11, Boqun Feng wrote:
>
> On Wed, Oct 30, 2024 at 12:57:14PM +0800, David Gow wrote:
> > From: José Expósito
> > Add a new procedural macro (`#[kunit_tests(kunit_test_suit_name)]`) to
> > run KUnit tests using a user-space like syntax.
> >
> > The macro, that should be u
On Tue, 03 Sep 2024 12:31:35 +0800, Ba Jing wrote:
> The macro GUEST_CODE_PIO_PORT is never referenced in the code,
> just remove it.
Applied to kvm-x86 selftests, thanks!
[1/1] hardware_disable_test: remove unused macro
https://github.com/kvm-x86/linux/commit/600aa88014e9
--
https://githu
Bumping this for Mingwei
Colton Lewis writes:
Extend pmu_counters_test to AMD CPUs.
As the AMD PMU is quite different from Intel with different events and
feature sets, this series introduces a new code path to test it,
specifically focusing on the core counters including the
PerfCtrExtCore
On Thu, 2024-10-31 at 19:25 +, Mark Brown wrote:
> ---
> base-commit: d17cd7b7cc92d37ee8b2df8f975fc859a261f4dc
Where can I find this base commit?
> change-id: 20231019-clone3-shadow-stack-15d40d2bf536
Add an epoll busy poll test using netdevsim.
This test is comprised of:
- busy_poller (via busy_poller.c)
- busy_poll_test.sh which loads netdevsim, sets up network namespaces,
and runs busy_poller to receive data and netcat to send data.
The selftest tests two different scenarios:
- bu
> The question is, if only extended moversions are used, what new tooling
> requirements are there? Can you test using only extended modversions?
>
> Luis
I'm not sure precisely what you're asking for. Do you want:
1. A kconfig that suppresses the emission of today's MODVERSIONS
format? This wou
Unlike with the normal stack there is no API for configuring the the shadow
stack for a new thread, instead the kernel will dynamically allocate a new
shadow stack with the same size as the normal stack. This appears to be due
to the shadow stack series having been in development since before the m
On Wed, 30 Oct 2024 14:37:31 -0600, Tycho Andersen wrote:
> Zbigniew mentioned at Linux Plumber's that systemd is interested in
> switching to execveat() for service execution, but can't, because the
> contents of /proc/pid/comm are the file descriptor which was used,
> instead of the path to the b
Hello Jiri,
Sorry for the late reply. Could you elaborate a bit reasons for the RTNL
interface implementation? Please find the questions inlined.
On 08.10.2024 15:52, Jiri Pirko wrote:
Tue, Oct 08, 2024 at 11:16:01AM CEST, anto...@openvpn.net wrote:
On 08/10/2024 10:58, Jiri Pirko wrote:
Tu
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Tue, 29 Oct 2024 11:47:13 +0100 you wrote:
> Notable changes from v10:
> * extended commit message of 23/23 with brief description of the output
> * Link to v10:
> https://lore.kernel.org/r/20241025-b4-ovpn-v10-0
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Wed, 30 Oct 2024 08:59:43 +0800 you wrote:
> ```
> readonly STATS="$(mktemp -p /tmp ns-XX)"
> readonly BASE=`basename $STATS`
> ```
> It could be a mistake to write to $BASE rather than $STATS, where $STATS
> i
On Tue, 29 Oct 2024 20:55:20 + Mina Almasry wrote:
> A few unrelated devmem TCP fixes bundled in a series for some
> convenience (if that's ok).
These two should go to net I presume? It's missing input validation.
Either way you gotta repost either as two properly separate series,
or combine
On Thu, 31 Oct 2024 11:00:05 +0100 Antonio Quartulli wrote:
> It seems some little changes to ovpn.yaml were not reflected in the
> generated files I committed.
>
> Specifically I changed some U32 to BE32 (IPv4 addresses) and files were
> not regenerated before committing.
>
> (I saw the failur
Hi,
On Wed, Oct 30, 2024 at 10:03 PM Paul E. McKenney wrote:
>
> > > > Note that:
> > > >
> > > > * Switching to real NMIs is impossible on many existing arm64 CPUs.
> > > > The hardware support simply isn't there. Pseudo-NMIs should work fine
> > > > and are (in nearly all cases) just as good as
The QEMU-ARM64 boot has failed with the Linux next-20241031 tag.
The boot log shows warnings at clockevents_register_device and followed
by rcu_preempt detected stalls.
However, the system did not proceed far enough to reach the login prompt.
The fvp-aemva, Qemu-arm64, Qemu-armv7 and Qemu-riscv64
On Thu, Oct 31, 2024 at 2:56 AM Sedat Dilek wrote:
>
> On Wed, Oct 30, 2024 at 10:14 PM Sami Tolvanen
> wrote:
> >
> > Hi Sedat,
> >
> > On Wed, Oct 30, 2024 at 2:00 PM Sedat Dilek wrote:
> > >
> > > Hi Sami,
> > >
> > > perfect timing: Nathan uploaded SLIM LLVM toolchain v19.1.3
> > >
> > > KB
Hi,
On Thu, Oct 31, 2024 at 02:10:14PM +0530, Naresh Kamboju wrote:
> The QEMU-ARM64 boot has failed with the Linux next-20241031 tag.
> The boot log shows warnings at clockevents_register_device and followed
> by rcu_preempt detected stalls.
>
> However, the system did not procee
On Thu, Oct 31, 2024 at 10:42:45AM +0100, Thomas Gleixner wrote:
> On Thu, Oct 31 2024 at 14:10, Naresh Kamboju wrote:
> > The QEMU-ARM64 boot has failed with the Linux next-20241031 tag.
> > The boot log shows warnings at clockevents_register_device and followed
> > by rcu_pr
It seems some little changes to ovpn.yaml were not reflected in the
generated files I committed.
Specifically I changed some U32 to BE32 (IPv4 addresses) and files were
not regenerated before committing.
(I saw the failure in patchwork about this)
It seems I'll have to send v12 after all.
C
On Wed, Oct 30, 2024 at 10:06:12PM -0700, Matthew Maurer wrote:
> On Wed, Oct 30, 2024 at 9:37 PM Luis Chamberlain wrote:
> >
> > On Thu, Oct 31, 2024 at 12:22:36PM +1100, Michael Ellerman wrote:
> > > Matthew Maurer writes:
> > > > Adds a new format for MODVERSIONS which stores each field in a s
In order to support LKMM atomics in Rust, add rust_helper_* for atomic
APIs. These helpers ensure the implementation of LKMM atomics in Rust is
the same as in C. This could save the maintenance burden of having two
similar atomic implementations in asm.
Originally-by: Mark Rutland
Signed-off-by:
To provide using LKMM atomics for Rust code, a generic `Atomic` is
added, currently `T` needs to be Send + Copy because these are the
straightforward usages and all basic types support this. The trait
`AllowAtomic` should be only ipmlemented inside atomic mod until the
generic atomic framework is m
xchg() and cmpxchg() are basic operations on atomic. Provide these based
on C APIs.
Note that cmpxchg() use the similar function signature as
compare_exchange() in Rust std: returning a `Result`, `Ok(old)` means
the operation succeeds and `Err(old)` means the operation fails. With
the compiler opt
Hi,
This is another RFC version of LKMM atomics in Rust, you can find the
previous versions:
v1:
https://lore.kernel.org/rust-for-linux/20240612223025.1158537-1-boqun.f...@gmail.com/
wip:
https://lore.kernel.org/rust-for-linux/20240322233838.868874-1-boqun.f...@gmail.com/
I add a few more peop
Preparation for atomic primitives. Instead of a suffix like _acquire, a
method parameter along with the corresponding generic parameter will be
used to specify the ordering of an atomic operations. For example,
atomic load() can be defined as:
impl Atomic {
pub fn load(&self, _
Add atomic support for raw pointer values, similar to `isize` and
`usize`, the representation type is selected based on CONFIG_64BIT.
`*mut T` is not `Send`, however `Atomic<*mut T>` definitely needs to be
a `Sync`, and that's the whole point of atomics: being able to have
multiple shared referenc
One important set of atomic operations is the arithmetic operations,
i.e. add(), sub(), fetch_add(), add_return(), etc. However it may not
make senses for all the types that `AllowAtomic` to have arithmetic
operations, for example a `Foo(u32)` may not have a reasonable add() or
sub(), plus subword
Add generic atomic support for `usize` and `isize`. Note that instead of
mapping directly to `atomic_long_t`, the represention type
(`AllowAtomic::Repr`) is selected based on CONFIG_64BIT. This reduces
the necessarity of creating `atomic_long_*` helpers, which could save
the binary size of kernel i
Add generic atomic support for basic unsigned types that have an
`AtomicIpml` with the same size and alignment.
Signed-off-by: Boqun Feng
---
rust/kernel/sync/atomic.rs | 80 ++
1 file changed, 80 insertions(+)
diff --git a/rust/kernel/sync/atomic.rs b/rust/k
From: Wedson Almeida Filho
Add a simple abstraction to guard critical code sections with an rcu
read lock.
Signed-off-by: Wedson Almeida Filho
Signed-off-by: Danilo Krummrich
---
rust/helpers/helpers.c | 1 +
rust/helpers/rcu.c | 13 +++
rust/kernel/sync.rs | 1 +
rust/ker
Memory barriers are building blocks for concurrent code, hence provide
a minimal set of them.
The compiler barrier, barrier(), is implemented in inline asm instead of
using core::sync::atomic::compiler_fence() because memory models are
different: kernel's atomics are implemented in inline asm ther
(This is more an RFC)
Add arithmetic operations support for `Atomic<*mut T>`. Currently the
semantics of arithmetic atomic operation is the same as pointer
arithmetic, that is, e.g. `Atomic<*mut u64>::add(1)` is adding 8
(`size_of::`) to the pointer value.
In Rust std library, there are two sets
Preparation for generic atomic implementation. To unify the
ipmlementation of a generic method over `i32` and `i64`, the C side
atomic methods need to be grouped so that in a generic method, they can
be referred as ::, otherwise their parameters and return
value are different between `i32` and `i64
From: José Expósito
Add a new procedural macro (`#[kunit_tests(kunit_test_suit_name)]`) to
run KUnit tests using a user-space like syntax.
The macro, that should be used on modules, transforms every `#[test]`
in a `kunit_case!` and adds a `kunit_unsafe_test_suite!` registering
all of them.
The
From: José Expósito
Add a couple of Rust const functions and macros to allow to develop
KUnit tests without relying on generated C code:
- The `kunit_unsafe_test_suite!` Rust macro is similar to the
`kunit_test_suite` C macro. It requires a NULL-terminated array of
test cases (see below).
From: José Expósito
In some cases, we need to call test-only code from outside the test
case, for example, to mock a function or a module.
In order to check whether we are in a test or not, we need to test if
`CONFIG_KUNIT` is set.
Unfortunately, we cannot rely only on this condition because:
-
On Fri, 1 Nov 2024 at 14:07, Boqun Feng wrote:
>
> Memory barriers are building blocks for concurrent code, hence provide
> a minimal set of them.
>
> The compiler barrier, barrier(), is implemented in inline asm instead of
> using core::sync::atomic::compiler_fence() because memory models are
> d
On 10/29/24 20:50, zhouyuhang wrote:
From: zhouyuhang
The libcap commit aca076443591 ("Make cap_t operations thread safe.")
added a __u8 mutex at the beginning of the struct _cap_struct, it changes
the offset of the members in the structure that breaks the assumption
made in the "struct libcap"
On Thu, 2024-10-31 at 14:27 -0700, Doug Anderson wrote:
> Hi,
>
> On Wed, Oct 30, 2024 at 10:03 PM Paul E. McKenney wrote:
> >
> > > > > Note that:
> > > > >
> > > > > * Switching to real NMIs is impossible on many existing arm64 CPUs.
> > > > > The hardware support simply isn't there. Pseudo-N
70 matches
Mail list logo
