Extend the existing regression test framework for s390x CPU subfunctions
to include tests for the Perform Locked Operation (PLO) subfunction
functions.
PLO was introduced in the very first 64-bit machine generation.
Hence it is assumed PLO is always installed in the Z Arch.
The test procedure foll
Extend the existing regression test framework for s390x CPU subfunctions
to include tests for the KMAC (Compute Message Authentication Code),
KMC (Cipher Message with Chaining), KM (Cipher Message) KIMD (Compute
Intermediate Message Digest) and KLMD (Compute Last Message Digest)
crypto functions.
Extend the existing regression test framework for s390x CPU subfunctions
to include tests for the KMCTR (Cipher Message with Counter) KMO
(Cipher Message with Output Feedback), KMF (Cipher Message with Cipher
Feedback) and PCC (Perform Cryptographic Computation) crypto functions.
The test procedur
Extend the existing regression test framework for s390x CPU subfunctions
to include tests for the PRNO (Perform Random Number Operation), KDSA
(Compute Digital Signature Authentication) and KMA (Cipher Message with
Authentication) crypto functions.
The test procedure follows the established patter
Introduce new regression tests to verify the ASM inline block in the SORTL
and DFLTCC CPU subfunctions for the s390x architecture. These tests ensure
that future changes to the ASM code are properly validated.
The test procedure:
1. Create a VM and request the KVM_S390_VM_CPU_MACHINE_SUBFUNC attr
This patch series introduces a set of regression tests for various s390x
CPU subfunctions in KVM. The tests ensure that the KVM implementation accurately
reflects the behavior of actual CPU instructions for these subfunctions.
The series adds tests for a total of 15 instructions across five patche
On Mon, 19 Aug 2024 23:15:44 +0100,
Oliver Upton wrote:
>
> On Mon, Aug 19, 2024 at 09:33:17AM -0700, Sean Christopherson wrote:
> > And other KVM maintainers, the big question is: if we do the above, would
> > now be
> > a decent time to bite the bullet and switch to the kernel's canonical arch
On Tue, Aug 20, 2024 at 2:03 AM Matteo Croce wrote:
>
> From: Matteo Croce
>
> Pass to register_btf_kfunc_id_set() a btf_kfunc_hook directly, instead
> of a bpf_prog_type.
> Many program types share the same kfunc hook, so some calls to
> register_btf_kfunc_id_set() can be removed.
>
> Tested com
On 8/17/2024 12:53 AM, Pratik R. Sampat wrote:
From: Michael Roth
SEV, SEV-ES, and SNP have a few corner cases where there is potential
for KVM_PRE_FAULT_MEMORY to behave differently depending on when it is
issued during initial guest setup. Exercising these various paths
requires a bit more fi
Add dmabuf information to page_pool stats:
$ ./cli.py --spec ../netlink/specs/netdev.yaml --dump page-pool-get
...
{'dmabuf': 10,
'id': 456,
'ifindex': 3,
'inflight': 1023,
'inflight-mem': 4190208},
{'dmabuf': 10,
'id': 455,
'ifindex': 3,
'inflight': 1023,
'inflight-mem': 4190208
ncdevmem is a devmem TCP netcat. It works similarly to netcat, but it
sends and receives data using the devmem TCP APIs. It uses udmabuf as
the dmabuf provider. It is compatible with a regular netcat running on
a peer, or a ncdevmem running on a peer.
In addition to normal netcat support, ncdevmem
Add documentation outlining the usage and details of devmem TCP.
Signed-off-by: Mina Almasry
Reviewed-by: Bagas Sanjaya
Reviewed-by: Donald Hunter
---
v16:
- Add documentation on unbinding the NIC from dmabuf (Donald).
- Add note that any dmabuf should work (Donald).
v9:
https://lore.kernel
Add an interface for the user to notify the kernel that it is done
reading the devmem dmabuf frags returned as cmsg. The kernel will
drop the reference on the frags to make them available for reuse.
Signed-off-by: Willem de Bruijn
Signed-off-by: Kaiyuan Zhang
Signed-off-by: Mina Almasry
Reviewe
In tcp_recvmsg_locked(), detect if the skb being received by the user
is a devmem skb. In this case - if the user provided the MSG_SOCK_DEVMEM
flag - pass it to tcp_recvmsg_devmem() for custom handling.
tcp_recvmsg_devmem() copies any data in the skb header to the linear
buffer, and returns a cmsg
For device memory TCP, we expect the skb headers to be available in host
memory for access, and we expect the skb frags to be in device memory
and unaccessible to the host. We expect there to be no mixing and
matching of device memory frags (unaccessible) with host memory frags
(accessible) in the
Make skb_frag_page() fail in the case where the frag is not backed
by a page, and fix its relevant callers to handle this case.
Signed-off-by: Mina Almasry
Reviewed-by: Eric Dumazet
---
v10:
- Fixed newly generated kdoc warnings found by patchwork. While we're
at it, fix the Return section
Implement a memory provider that allocates dmabuf devmem in the form of
net_iov.
The provider receives a reference to the struct netdev_dmabuf_binding
via the pool->mp_priv pointer. The driver needs to set this pointer for
the provider in the net_iov.
The provider obtains a reference on the netde
Convert netmem to be a union of struct page and struct netmem. Overload
the LSB of struct netmem* to indicate that it's a net_iov, otherwise
it's a page.
Currently these entries in struct page are rented by the page_pool and
used exclusively by the net stack:
struct {
unsigned long pp_mag
Implement netdev devmem allocator. The allocator takes a given struct
netdev_dmabuf_binding as input and allocates net_iov from that
binding.
The allocation simply delegates to the binding's genpool for the
allocation logic and wraps the returned memory region in a net_iov
struct.
Signed-off-by:
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. The entries in the sg_table from
mapping will be inserted into a genpool
API takes the dma-buf fd as input, and binds it to the netdevice. The
user can specify the rx queues to bind the dma-buf to.
Suggested-by: Stanislav Fomichev
Signed-off-by: Mina Almasry
Reviewed-by: Donald Hunter
Reviewed-by: Jakub Kicinski
---
v16:
- Use subset-of: queue queue-id instead of
Add netdev_rx_queue_restart(), which resets an rx queue using the
queue API recently merged[1].
The queue API was merged to enable the core net stack to reset individual
rx queues to actuate changes in the rx queue's configuration. In later
patches in this series, we will use netdev_rx_queue_resta
v21: https://patchwork.kernel.org/project/netdevbpf/list/?series=880735&state=*
v20 addressed some comments and resolved a test failure, but introduced
an unfortunate build error with a config edge case I wasn't testing. v21
simply resolves that error.
Major Changes:
- Resolve build error wi
On Mon, Aug 19, 2024 at 6:53 PM Jakub Kicinski wrote:
>
> On Mon, 19 Aug 2024 00:44:27 +0900 Taehee Yoo wrote:
> > > @@ -9537,6 +9540,10 @@ static int dev_xdp_attach(struct net_device *dev,
> > > struct netlink_ext_ack *extack
> > > NL_SET_ERR_MSG(extack, "Native and gener
On Sat, Aug 17, 2024 at 01:36:59PM -0700, Jakub Kicinski wrote:
> Looking at timestamped output of netdev CI reveals that
> most of the time in forwarding tests for custom route
> hashing is spent on a single case, namely the test which
> uses ping (mausezahn does not support flow labels).
>
> On
On Mon, Aug 19, 2024 at 05:42:17PM -0700, Jakub Kicinski wrote:
> diff --git a/tools/testing/selftests/net/settings
> b/tools/testing/selftests/net/settings
> index ed8418e8217a..a38764182822 100644
> --- a/tools/testing/selftests/net/settings
> +++ b/tools/testing/selftests/net/settings
> @@ -1 +
Hi
I apologize for the confusion.
I mistakenly thought that my previous email
(https://lore.kernel.org/all/20240820023447.29002-1-hao...@linux.dev/)
didn't send due to network issues on my computer, so I resent it.
However, it seems that was not the case.
Please kindly disregard this patch
On Tue, Aug 20, 2024 at 09:48:50AM +0800, Levi Zim wrote:
> On 2024-08-20 01:00, Charlie Jenkins wrote:
> > On Mon, Aug 19, 2024 at 01:55:57PM +0800, Levi Zim wrote:
> > > On 2024-03-22 22:06, Palmer Dabbelt wrote:
> > > > On Thu, 01 Feb 2024 18:28:06 PST (-0800), Charlie Jenkins wrote:
> > > > > O
From: Hao Ge
Smatch reported the following warning:
./tools/testing/selftests/bpf/testing_helpers.c:455 get_xlated_program()
warn: variable dereferenced before check 'buf' (see line 454)
It seems correct,so let's modify it based on it's suggestion.
Actually,commit b23ed4d74c4d ("selftes
From: Hao Ge
Smatch reported the following warning:
./tools/testing/selftests/bpf/testing_helpers.c:455 get_xlated_program()
warn: variable dereferenced before check 'buf' (see line 454)
It seems correct,so let's modify it based on it's suggestion.
Actually,commit b23ed4d74c4d ("selftes
On 2024-08-20 01:00, Charlie Jenkins wrote:
On Mon, Aug 19, 2024 at 01:55:57PM +0800, Levi Zim wrote:
On 2024-03-22 22:06, Palmer Dabbelt wrote:
On Thu, 01 Feb 2024 18:28:06 PST (-0800), Charlie Jenkins wrote:
On Wed, Jan 31, 2024 at 11:59:43PM +0800, Yangyu Chen wrote:
On Wed, 2024-01-31 at
Adds test suite for integer based power function.
Signed-off-by: Luis Felipe Hernandez
---
Changes in v3:
- Fix compiler warning: explicitly define constant as unsigned int
- Add changes in patch revisions
Changes in v2:
- Address review feedback
- Add kconfig entry
- Use correct dir and file
A few tests check if nettest exists in the $PATH before adding
$PWD to $PATH and re-checking. They don't discard stderr on
the first check (and nettest is built as part of selftests,
so it's pretty normal for it to not be available in system $PATH).
This leads to output noise:
which: no nettest
On Sun, 18 Aug 2024 19:05:46 +0300 Ido Schimmel wrote:
> Nice improvement. fib_rule_tests.sh can also benefit from this helper
> and so does vrf_route_leaking.sh which assumes 'nettest' is available
> in the working directory.
>
> Do you want to fold the diff below into v2 (I tested it)?
Perfect!
On 7/31/24 3:01 AM, Michal Luczaj wrote:
Series takes care of few bugs and missing features with the aim to improve
the test coverage of sockmap/sockhash.
Last patch is a create_pair() rewrite making use of
__attribute__((cleanup)) to handle socket fd lifetime.
Applied to bpf-next/net. Thanks.
From: Matteo Croce
Pass to register_btf_kfunc_id_set() a btf_kfunc_hook directly, instead
of a bpf_prog_type.
Many program types share the same kfunc hook, so some calls to
register_btf_kfunc_id_set() can be removed.
Tested compiling the kernel with -Werror=enum-conversion to catch all
the occou
On 8/17/24 7:13 PM, Geliang Tang wrote:
Take a look at a recent example [0]. The mptcp test is under a cgroup
already
and has the cgroup setup. An extra "cgroup/getsockopt" prog should be
enough.
That prog can walk the msk->conn_list and use bpf_rdonly_cast (or the
>> bpf_core_cast macro in libb
On Tue, Aug 13, 2024 at 04:55:27PM +0100, Conor Dooley wrote:
> On Mon, Aug 12, 2024 at 05:45:30PM -0700, Charlie Jenkins wrote:
> > On Fri, Aug 09, 2024 at 11:31:15PM +0100, Conor Dooley wrote:
> > > On Tue, Aug 06, 2024 at 05:31:36PM -0700, Charlie Jenkins wrote:
> > > > xtheadvector is a custom
On Mon, 19 Aug 2024 00:44:27 +0900 Taehee Yoo wrote:
> > @@ -9537,6 +9540,10 @@ static int dev_xdp_attach(struct net_device *dev,
> > struct netlink_ext_ack *extack
> > NL_SET_ERR_MSG(extack, "Native and generic XDP
> > can't be active at the same time");
> >
On 8/16/24 12:03 PM, Jakub Sitnicki wrote:
On Wed, Aug 14, 2024 at 06:14 PM +02, Michal Luczaj wrote:
On 8/6/24 19:45, Jakub Sitnicki wrote:
On Tue, Aug 06, 2024 at 07:18 PM +02, Michal Luczaj wrote:
Great, thanks for the review. With this completed, I guess we can unwind
the (mail) stack to [
On Mon, 19 Aug 2024 16:38:32 -0400 Mina Almasry wrote:
> Looks like in this iteration I resolved the previous test failure, but
> introduced a build regression with certain configs:
>
> ld: vmlinux.o: in function `netdev_rx_queue_restart':
> (.text+0x6a4133): undefined reference to `page_pool_chec
On Mon, Aug 19, 2024 at 09:33:17AM -0700, Sean Christopherson wrote:
> And other KVM maintainers, the big question is: if we do the above, would now
> be
> a decent time to bite the bullet and switch to the kernel's canonical arch
> paths,
> i.e. arm64, s390, and x86? I feel like if we're ever g
On Mon, Aug 19, 2024 at 9:15 PM Liam R. Howlett wrote:
>
> * Pedro Falcato [240816 20:18]:
> > Move can_modify_vma to vma.h so it can be inlined properly (with
> > the intent to remove can_modify_mm callsites).
> >
> > Signed-off-by: Pedro Falcato
> > ---
> > mm/mseal.c | 17 -
>
On Sun, Aug 18, 2024 at 11:54 PM Mina Almasry wrote:
>
> v20:
> https://patchwork.kernel.org/project/netdevbpf/list/?series=879373&state=*
>
>
> v20 aims to resolve a couple of bug reports against v19, and addresses
> some review comments around the page_pool_check_memory_provider
> mechanis
* Pedro Falcato [240816 20:19]:
> Delegate all can_modify checks to the proper places. Unmap checks are
> done in do_unmap (et al). The source VMA check is done purposefully
> before unmapping, to keep the original mseal semantics.
>
> Signed-off-by: Pedro Falcato
Reviewed-by: Liam R. Howlett
* Pedro Falcato [240816 20:19]:
> Avoid taking an extra trip down the mmap tree by checking the vmas
> directly. mprotect (per POSIX) tolerates partial failure.
>
> Signed-off-by: Pedro Falcato
Reviewed-by: Liam R. Howlett
> ---
> mm/mprotect.c | 12 +++-
> 1 file changed, 3 insertio
* Pedro Falcato [240816 20:18]:
> With no more users in the tree, we can finally remove can_modify_mm().
>
> Signed-off-by: Pedro Falcato
Reviewed-by: Liam R. Howlett
> ---
> mm/internal.h | 14 --
> mm/mseal.c| 21 -
> 2 files changed, 35 deletions(-)
>
* Pedro Falcato [240816 20:18]:
> Replace can_modify_mm_madv() with a single vma variant, and associated
> checks in madvise.
>
> While we're at it, also invert the order of checks in:
> if (unlikely(is_ro_anon(vma) && !can_modify_vma(vma))
>
> Checking if we can modify the vma itself (through
* Pedro Falcato [240816 20:18]:
> We were doing an extra mmap tree traversal just to check if the entire
> range is modifiable. This can be done when we iterate through the VMAs
> instead.
>
> Signed-off-by: Pedro Falcato
Although this has the side effect of potentially splitting the first vma
* Pedro Falcato [240816 20:18]:
> Move can_modify_vma to vma.h so it can be inlined properly (with
> the intent to remove can_modify_mm callsites).
>
> Signed-off-by: Pedro Falcato
> ---
> mm/mseal.c | 17 -
> mm/vma.h | 28
> 2 files changed, 28 i
On Wed, Aug 14, 2024 at 06:14 PM +02, Michal Luczaj wrote:
> On 8/6/24 19:45, Jakub Sitnicki wrote:
>> On Tue, Aug 06, 2024 at 07:18 PM +02, Michal Luczaj wrote:
>>> Great, thanks for the review. With this completed, I guess we can unwind
>>> the (mail) stack to [1]. Is that ingress-to-local et al.
On 8/19/24 12:41 PM, John Hubbard wrote:
On 8/18/24 8:55 PM, Muhammad Usama Anjum wrote:
On 8/7/24 3:22 PM, Muhammad Usama Anjum wrote:
On 5/9/24 11:16 AM, Kees Cook wrote:
...
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
arm-linux-gnueabihf-gcc -Wall -Wno-nonnull -D_GNU_SOURCE=
-Wl,-z,ma
select_local_address() and select_signal_address() both select an
endpoint entry from the list inside an RCU protected section, but return
a reference to it, to be read later on. If the entry is dereferenced
after the RCU unlock, reading info could cause a Use-after-Free.
A simple solution is to c
This case was not covered, and the wrong ID was set before the previous
commit.
The rest is not modified, it is just that it will increase the code
coverage.
The right address ID can be verified by looking at the packet traces. We
could automate that using Netfilter with some cBPF code for exampl
When reacting upon the reception of an ADD_ADDR, the in-kernel PM first
looks for fullmesh endpoints. If there are some, it will pick them,
using their entry ID.
It should set the ID 0 when using the endpoint corresponding to the
initial subflow, it is a special case imposed by the MPTCP specs.
N
The ID 0 is specific per MPTCP connections. The per netns entries cannot
have this special ID 0 then.
But that's different for the userspace PM where the entries are per
connection, they can then use this special ID 0.
Fixes: f40be0db0b76 ("mptcp: unify pm get_flags_and_ifindex_by_id")
Cc: sta...
The limits might have changed in between, it is best to check them
before accepting new ADD_ADDR.
Fixes: d0876b2284cf ("mptcp: add the incoming RM_ADDR support")
Cc: sta...@vger.kernel.org
Reviewed-by: Mat Martineau
Signed-off-by: Matthieu Baerts (NGI0)
---
net/mptcp/pm_netlink.c | 4 ++--
1 fi
Adding the following warning ...
WARN_ON_ONCE(msk->pm.add_addr_accepted == 0)
... before decrementing the add_addr_accepted counter helped to find a
bug when running the "remove single subflow" subtest from the
mptcp_join.sh selftest.
Removing a 'subflow' endpoint will first trigger a RM_ADDR,
Adding the following warning ...
WARN_ON_ONCE(msk->pm.local_addr_used == 0)
... before decrementing the local_addr_used counter helped to find a bug
when running the "remove single address" subtest from the mptcp_join.sh
selftests.
Removing a 'signal' endpoint will trigger the removal of all s
This helper is confusing. It is in pm.c, but it is specific to the
in-kernel PM and it cannot be used by the userspace one. Also, it simply
calls one in-kernel specific function with the PM lock, while the
similar mptcp_pm_remove_addr() helper requires the PM lock.
What's left is the pr_debug(), w
After having flushed endpoints that didn't cause the creation of new
subflows, it is important to check endpoints can be re-created, re-using
previously used IDs.
Before the previous commit, the client would not have been able to
re-create the subflow that was previously rejected.
The 'Fixes' tag
If no subflows are attached to the 'subflow' endpoints that are being
flushed, the corresponding addr IDs will not be marked as available
again.
Mark all ID as being available when flushing all the 'subflow'
endpoints, and reset local_addr_used counter to cover these cases.
Note that mptcp_pm_rem
This test extends "delete and re-add" to validate the previous commit. A
new 'subflow' endpoint is added, but the subflow request will be
rejected. The result is that no subflow will be established from this
address.
Later, the endpoint is removed and re-added after having cleared the
firewall rul
If no subflow is attached to the 'subflow' endpoint that is being
removed, the addr ID will not be marked as available again.
Mark the linked ID as available when removing the 'subflow' endpoint if
no subflow is attached to it.
While at it, the local_addr_used counter is decremented if the ID was
This test extends "delete re-add signal" to validate the previous
commit. An extra address is announced by the server, but this address
cannot be used by the client. The result is that no subflow will be
established to this address.
Later, the server will delete this extra endpoint, and set a new
If no subflow is attached to the 'signal' endpoint that is being
removed, the addr ID will not be marked as available again.
Mark the linked ID as available when removing the address entry from the
list to cover this case.
Fixes: b6c08380860b ("mptcp: remove addr and subflow in PM netlink")
Cc: s
ions(+), 74 deletions(-)
---
base-commit: 565d121b69980637f040eb4d84289869cdaabedf
change-id: 20240819-net-mptcp-pm-reusing-id-eb08827b7be6
Best regards,
--
Matthieu Baerts (NGI0)
On Fri, Aug 16, 2024 at 1:23 PM Pratik R. Sampat
wrote:
>
> This series primarily introduces SEV-SNP test for the kernel selftest
> framework. It tests boot, ioctl, pre fault, and fallocate in various
> combinations to exercise both positive and negative launch flow paths.
>
> Patch 1 - Adds a wra
On 8/18/24 8:55 PM, Muhammad Usama Anjum wrote:
On 8/7/24 3:22 PM, Muhammad Usama Anjum wrote:
On 5/9/24 11:16 AM, Kees Cook wrote:
On Wed, May 08, 2024 at 07:54:13PM -0700, John Hubbard wrote:
Didn't we learn recently, though, that -static-pie is gcc 8.1+, while the
kernel's minimum gcc versi
On Mon, Aug 19, 2024 at 12:14:13PM -0700, Kuniyuki Iwashima wrote:
> From: Kuniyuki Iwashima
> Date: Mon, 19 Aug 2024 12:07:04 -0700
> > > > 488 mssind = (cookie & (3 << 6)) >> 6;
> > > > 489 if (ctx->ipv4) {
> > > > 490 if (mssind > ARRAY_SIZE(msstab4))
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
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
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
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
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
Since multiple architectures have support for shadow stacks and we need to
select support for this feature in several places in the generic code
provide a generic config option that the architectures can select.
Suggested-by: David Hildenbrand
Acked-by: David Hildenbrand
Reviewed-by: Deepak Gupt
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
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
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
On Fri, 14 Jun 2024 12:43:22 -0400
Steven Rostedt wrote:
> Shuah,
>
> Can you take this through your tree?
Ping.
-- Steve
>
> Thanks,
>
> -- Steve
>
>
> On Wed, 15 May 2024 01:36:20 -0400
> Steven Rostedt wrote:
>
> > From: "Steven Rostedt (Google)"
> >
> > The function "scheduler_tic
From: Kuniyuki Iwashima
Date: Mon, 19 Aug 2024 12:07:04 -0700
> > > 488 mssind = (cookie & (3 << 6)) >> 6;
> > > 489 if (ctx->ipv4) {
> > > 490 if (mssind > ARRAY_SIZE(msstab4))
> > >^
> > > Should be >= instead of >.
From: Dan Carpenter
Date: Mon, 19 Aug 2024 21:57:57 +0300
> On Mon, Aug 19, 2024 at 09:54:00PM +0300, Dan Carpenter wrote:
> > Hello Kuniyuki Iwashima,
> >
> > Commit a74712241b46 ("selftest: bpf: Test
> > bpf_sk_assign_tcp_reqsk().") from Jan 15, 2024 (linux-next), leads to
> > the following Sma
Hello Hou Tao,
This is a semi-automatic email about new static checker warnings.
Commit b4b7a4099b8c ("selftests/bpf: Factor out get_xlated_program()
helper") from Jan 5, 2024, leads to the following Smatch complaint:
./tools/testing/selftests/bpf/testing_helpers.c:455 get_xlated_program()
Hello Joe Stringer,
Commit de375f4e91e3 ("selftests/bpf: Add C tests for reference
tracking") from Oct 2, 2018 (linux-next), leads to the following
Smatch static checker warning:
./tools/testing/selftests/bpf/progs/test_sk_lookup_kern.c:70
sk_lookup_success()
warn: potential poin
On Mon, Aug 19, 2024 at 09:54:00PM +0300, Dan Carpenter wrote:
> Hello Kuniyuki Iwashima,
>
> Commit a74712241b46 ("selftest: bpf: Test
> bpf_sk_assign_tcp_reqsk().") from Jan 15, 2024 (linux-next), leads to
> the following Smatch static checker warning:
>
> tools/testing/selftests/bpf/prog
On Mon, Aug 19, 2024 at 03:47:16PM -0300, Jason Gunthorpe wrote:
> On Mon, Aug 19, 2024 at 11:38:22AM -0700, Nicolin Chen wrote:
> > On Mon, Aug 19, 2024 at 03:28:11PM -0300, Jason Gunthorpe wrote:
> > > On Mon, Aug 19, 2024 at 11:19:39AM -0700, Nicolin Chen wrote:
> > >
> > > > > But nesting enab
Hello Kuniyuki Iwashima,
Commit a74712241b46 ("selftest: bpf: Test
bpf_sk_assign_tcp_reqsk().") from Jan 15, 2024 (linux-next), leads to
the following Smatch static checker warning:
tools/testing/selftests/bpf/progs/test_tcp_custom_syncookie.c:493
tcp_validate_cookie()
warn: off
On Mon, Aug 19, 2024 at 11:38:22AM -0700, Nicolin Chen wrote:
> On Mon, Aug 19, 2024 at 03:28:11PM -0300, Jason Gunthorpe wrote:
> > On Mon, Aug 19, 2024 at 11:19:39AM -0700, Nicolin Chen wrote:
> >
> > > > But nesting enablment with out viommu is alot less useful than I had
> > > > thought :(
> >
On Mon, Aug 19, 2024 at 03:28:11PM -0300, Jason Gunthorpe wrote:
> On Mon, Aug 19, 2024 at 11:19:39AM -0700, Nicolin Chen wrote:
>
> > > But nesting enablment with out viommu is alot less useful than I had
> > > thought :(
> >
> > Actually, without viommu, the hwpt cache invalidate alone could
>
On Mon, Aug 19, 2024 at 10:58 AM Piotr Zalewski
wrote:
>
> Make timespec pointers, pointers to const in checklist function. As a
> consequence, make list parameter in checklist function pointer to const
> as well. Const-correctness increases readability.
>
> Improvement was found by running cppche
On Mon, Aug 19, 2024 at 11:19:39AM -0700, Nicolin Chen wrote:
> > But nesting enablment with out viommu is alot less useful than I had
> > thought :(
>
> Actually, without viommu, the hwpt cache invalidate alone could
> still support non-SVA case?
That is what I thought, but doesn't the guest st
On Mon, Aug 19, 2024 at 11:10:03AM -0700, Nicolin Chen wrote:
> On Mon, Aug 19, 2024 at 02:33:32PM -0300, Jason Gunthorpe wrote:
> > On Thu, Aug 15, 2024 at 05:21:57PM -0700, Nicolin Chen wrote:
> >
> > > > Why not? The idev becomes linked to the viommu when the dev id is set
> > >
> > > > Unless
On Mon, Aug 19, 2024 at 03:20:35PM -0300, Jason Gunthorpe wrote:
> On Mon, Aug 19, 2024 at 10:49:56AM -0700, Nicolin Chen wrote:
> > On Mon, Aug 19, 2024 at 02:30:56PM -0300, Jason Gunthorpe wrote:
> > > On Thu, Aug 15, 2024 at 04:51:39PM -0700, Nicolin Chen wrote:
> > > > On Thu, Aug 15, 2024 at 0
On Mon, Aug 19, 2024 at 10:49:56AM -0700, Nicolin Chen wrote:
> On Mon, Aug 19, 2024 at 02:30:56PM -0300, Jason Gunthorpe wrote:
> > On Thu, Aug 15, 2024 at 04:51:39PM -0700, Nicolin Chen wrote:
> > > On Thu, Aug 15, 2024 at 08:24:05PM -0300, Jason Gunthorpe wrote:
> > > > On Wed, Aug 07, 2024 at 0
On Mon, Aug 19, 2024 at 02:36:15PM -0300, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2024 at 05:50:06PM -0700, Nicolin Chen wrote:
>
> > Though only driver would know whether it would eventually access
> > the vdev_id list, I'd like to keep things in the way of having a
> > core-managed VIOMMU objec
On Mon, Aug 19, 2024 at 02:33:32PM -0300, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2024 at 05:21:57PM -0700, Nicolin Chen wrote:
>
> > > Why not? The idev becomes linked to the viommu when the dev id is set
> >
> > > Unless we are also going to enforce the idev is always attached to a
> > > neste
Make timespec pointers, pointers to const in checklist function. As a
consequence, make list parameter in checklist function pointer to const
as well. Const-correctness increases readability.
Improvement was found by running cppcheck tool on the patched file as
follows:
```
cppcheck --enable=all \
On Mon, Aug 19, 2024 at 02:30:56PM -0300, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2024 at 04:51:39PM -0700, Nicolin Chen wrote:
> > On Thu, Aug 15, 2024 at 08:24:05PM -0300, Jason Gunthorpe wrote:
> > > On Wed, Aug 07, 2024 at 01:10:49PM -0700, Nicolin Chen wrote:
> > > > @@ -946,4 +947,40 @@ stru
On Thu, Aug 15, 2024 at 05:50:06PM -0700, Nicolin Chen wrote:
> Though only driver would know whether it would eventually access
> the vdev_id list, I'd like to keep things in the way of having a
> core-managed VIOMMU object (IOMMU_VIOMMU_TYPE_DEFAULT), so the
> viommu invalidation handler could h
On Thu, Aug 15, 2024 at 05:21:57PM -0700, Nicolin Chen wrote:
> > Why not? The idev becomes linked to the viommu when the dev id is set
>
> > Unless we are also going to enforce the idev is always attached to a
> > nested then I don't think we need to check it here.
> >
> > Things will definatel
1 - 100 of 148 matches
Mail list logo
