search for: vmaddr_cid_ani

From: Stefan Hajnoczi <stefanha at redhat.com> The vsock_test.c program runs a test suite of AF_VSOCK test cases. Signed-off-by: Stefan Hajnoczi <stefanha at redhat.com> Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- v2: * Drop unnecessary includes [Stefan] * Aligned with the current SPDX [Stefano] * Set MULTICONN_NFDS to 100 [Stefano] * Change (i % 1) in (i

Hi Stefan, I'm thinking about dividing this test into single applications, one for each test, do you think it makes sense? Or is it just a useless complication? Thanks, Stefano On Thu, Aug 1, 2019 at 5:27 PM Stefano Garzarella <sgarzare at redhat.com> wrote: > > From: Stefan Hajnoczi <stefanha at redhat.com> > > The vsock_test.c program runs a test suite of AF_VSOCK

Hi Stefan, I'm thinking about dividing this test into single applications, one for each test, do you think it makes sense? Or is it just a useless complication? Thanks, Stefano On Thu, Aug 1, 2019 at 5:27 PM Stefano Garzarella <sgarzare at redhat.com> wrote: > > From: Stefan Hajnoczi <stefanha at redhat.com> > > The vsock_test.c program runs a test suite of AF_VSOCK

The vsock_diag.ko module already has a test suite but the core AF_VSOCK functionality has no tests. This patch series adds several test cases that exercise AF_VSOCK SOCK_STREAM socket semantics (send/recv, connect/accept, half-closed connections, simultaneous connections). Stefan: Do you think we should have a single application or is better to split it in single tests (e.g.

On 2019/6/28 ??8:36, Stefano Garzarella wrote: > Some callbacks used by the upper layers can run while we are in the > .remove(). A potential use-after-free can happen, because we free > the_virtio_vsock without knowing if the callbacks are over or not. > > To solve this issue we move the assignment of the_virtio_vsock at the > end of .probe(), when we finished all the

On 2019/6/28 ??8:36, Stefano Garzarella wrote: > Some callbacks used by the upper layers can run while we are in the > .remove(). A potential use-after-free can happen, because we free > the_virtio_vsock without knowing if the callbacks are over or not. > > To solve this issue we move the assignment of the_virtio_vsock at the > end of .probe(), when we finished all the

This patch adds the support of multiple transports in the VSOCK core. With the multi-transports support, we can use vsock with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Major changes: - vsock core module can be loaded regardless of the transports - vsock_core_init() and vsock_core_exit() are renamed to

This patch adds the support of multiple transports in the VSOCK core. With the multi-transports support, we can use vsock with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Major changes: - vsock core module can be loaded interdependently of the transports - each 'struct virtio_transport' has a new feature fields

On 2019/7/3 ??6:41, Stefano Garzarella wrote: > On Wed, Jul 03, 2019 at 05:53:58PM +0800, Jason Wang wrote: >> On 2019/6/28 ??8:36, Stefano Garzarella wrote: >>> Some callbacks used by the upper layers can run while we are in the >>> .remove(). A potential use-after-free can happen, because we free >>> the_virtio_vsock without knowing if the callbacks are over

On 2019/7/3 ??6:41, Stefano Garzarella wrote: > On Wed, Jul 03, 2019 at 05:53:58PM +0800, Jason Wang wrote: >> On 2019/6/28 ??8:36, Stefano Garzarella wrote: >>> Some callbacks used by the upper layers can run while we are in the >>> .remove(). A potential use-after-free can happen, because we free >>> the_virtio_vsock without knowing if the callbacks are over

Remote peer is always the host, so we set VMADDR_CID_HOST as remote CID instead of VMADDR_CID_ANY. Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- net/vmw_vsock/hyperv_transport.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c index 4f47af2054dd..306310794522 100644 ---

When we are looking for a socket bound to a specific address, we also have to take into account the CID. This patch is useful with multi-transports support because it allows the binding of the same port with different CID, and it prevents a connection to a wrong socket bound to the same port, but with different CID. Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> ---

When we are looking for a socket bound to a specific address, we also have to take into account the CID. This patch is useful with multi-transports support because it allows the binding of the same port with different CID, and it prevents a connection to a wrong socket bound to the same port, but with different CID. Reviewed-by: Stefan Hajnoczi <stefanha at redhat.com> Signed-off-by:

On Sat, Aug 26, 2023 at 08:59:00PM +0300, Arseniy Krasnov wrote: >This adds two tests for 'shutdown()' call. It checks that SIGPIPE is >sent when MSG_NOSIGNAL is not set and vice versa. Both flags SHUT_WR >and SHUT_RD are tested. > >Signed-off-by: Arseniy Krasnov <avkrasnov at salutedevices.com> >--- > tools/testing/vsock/vsock_test.c | 138

> From: Stefano Garzarella [mailto:sgarzare at redhat.com] > Sent: Wednesday, October 23, 2019 11:56 AM Thanks a lot for working on this! > With the multi-transports support, we can use vsock with nested VMs (using > also different hypervisors) loading both guest->host and > host->guest transports at the same time. > > Major changes: > - vsock core module can be

> From: Stefano Garzarella [mailto:sgarzare at redhat.com] > Sent: Wednesday, October 23, 2019 11:56 AM Thanks a lot for working on this! > With the multi-transports support, we can use vsock with nested VMs (using > also different hypervisors) loading both guest->host and > host->guest transports at the same time. > > Major changes: > - vsock core module can be

The vsock_diag.ko module already has a test suite but the core AF_VSOCK functionality has no tests. This patch series adds several test cases that exercise AF_VSOCK SOCK_STREAM socket semantics (send/recv, connect/accept, half-closed connections, simultaneous connections). The v1 of this series was originally sent by Stefan. v3: - Patch 6: * check the byte received in the recv_byte() * use

As a preparation to support multiple transports, this patch adds the 'transport' member at the 'struct vsock_sock'. This new field is initialized during the creation in the __vsock_create() function. This patch also renames the global 'transport' pointer to 'transport_single', since for now we're only supporting a single transport registered at run-time.

As a preparation to support multiple transports, this patch adds the 'transport' member at the 'struct vsock_sock'. This new field is initialized during the creation in the __vsock_create() function. This patch also renames the global 'transport' pointer to 'transport_single', since for now we're only supporting a single transport registered at run-time.

Some callbacks used by the upper layers can run while we are in the .remove(). A potential use-after-free can happen, because we free the_virtio_vsock without knowing if the callbacks are over or not. To solve this issue we move the assignment of the_virtio_vsock at the end of .probe(), when we finished all the initialization, and at the beginning of .remove(), before to release resources. For