similar to: [PATCH] VSOCK: Don't call vsock_stream_has_data in atomic context

When using the host personality, VMCI will grab a mutex for any queue pair access. In the detach callback for the vmci vsock transport, we call vsock_stream_has_data while holding a spinlock, and vsock_stream_has_data will access a queue pair. To avoid this, we can simply omit calling vsock_stream_has_data for host side queue pairs, since the QPs are empty per default when the guest has detached.

When using the host personality, VMCI will grab a mutex for any queue pair access. In the detach callback for the vmci vsock transport, we call vsock_stream_has_data while holding a spinlock, and vsock_stream_has_data will access a queue pair. To avoid this, we can simply omit calling vsock_stream_has_data for host side queue pairs, since the QPs are empty per default when the guest has detached.

If skb_recv_datagram returns an skb, we should ignore the err value returned. Otherwise, datagram receives will return EAGAIN when they have to wait for a datagram. Acked-by: Adit Ranadive <aditr at vmware.com> Signed-off-by: Jorgen Hansen <jhansen at vmware.com> --- net/vmw_vsock/vmci_transport.c | 7 ++----- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git

If skb_recv_datagram returns an skb, we should ignore the err value returned. Otherwise, datagram receives will return EAGAIN when they have to wait for a datagram. Acked-by: Adit Ranadive <aditr at vmware.com> Signed-off-by: Jorgen Hansen <jhansen at vmware.com> --- net/vmw_vsock/vmci_transport.c | 7 ++----- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git

If a server side socket is bound to an address, but not in the listening state yet, incoming connection requests should receive a reset control packet in response. However, the function used to send the reset silently drops the reset packet if the sending socket isn't bound to a remote address (as is the case for a bound socket not yet in the listening state). This change fixes this by using

On Fri, Oct 11, 2019 at 03:07:57PM +0200, Stefano Garzarella wrote: > vmci_transport never allowed half-closed socket on the host side. > Since we want to have the same behaviour across all transports, we > add a section in the "Implementation notes". > > Cc: Jorgen Hansen <jhansen at vmware.com> > Cc: Adit Ranadive <aditr at vmware.com> > Signed-off-by:

We are implementing a test suite for the VSOCK sockets and we discovered that vmci_transport never allowed half-closed socket on the host side. As Jorgen explained [1] this is due to the implementation of VMCI. Since we want to have the same behaviour across all transports, this series adds a section in the "Implementation notes" to exaplain this behaviour, and changes the

We are implementing a test suite for the VSOCK sockets and we discovered that vmci_transport never allowed half-closed socket on the host side. As Jorgen explained [1] this is due to the implementation of VMCI. Since we want to have the same behaviour across all transports, this series adds a section in the "Implementation notes" to exaplain this behaviour, and changes the

On Fri, Sep 21, 2018 at 12:31:05AM -0700, Jorgen Hansen wrote: > When adding a VMCI resource, the check for an existing entry > would ignore that the new entry could be a wildcard. This could > result in multiple resource entries that would match a given > handle. One disastrous outcome of this is that the > refcounting used to ensure that delayed callbacks for VMCI > datagrams

On Fri, Sep 21, 2018 at 12:31:05AM -0700, Jorgen Hansen wrote: > When adding a VMCI resource, the check for an existing entry > would ignore that the new entry could be a wildcard. This could > result in multiple resource entries that would match a given > handle. One disastrous outcome of this is that the > refcounting used to ensure that delayed callbacks for VMCI > datagrams

In the vsock vmci_transport driver, sock_put wasn't safe to call in interrupt context, since that may call the vsock destructor which in turn calls several functions that should only be called from process context. This change defers the callling of these functions to a worker thread. All these functions were deallocation of resources related to the transport itself. Furthermore, an unused

In the vsock vmci_transport driver, sock_put wasn't safe to call in interrupt context, since that may call the vsock destructor which in turn calls several functions that should only be called from process context. This change defers the callling of these functions to a worker thread. All these functions were deallocation of resources related to the transport itself. Furthermore, an unused

A recent commit (3b4477d2dcf2) converted the sk_state to use TCP constants. In that change, vmci_transport_handle_detach was changed such that sk->sk_state was set to TCP_CLOSE before we test whether it is TCP_SYN_SENT. This change moves the sk_state change back to the original locations in that function. Signed-off-by: Jorgen Hansen <jhansen at vmware.com> ---

A recent commit (3b4477d2dcf2) converted the sk_state to use TCP constants. In that change, vmci_transport_handle_detach was changed such that sk->sk_state was set to TCP_CLOSE before we test whether it is TCP_SYN_SENT. This change moves the sk_state change back to the original locations in that function. Signed-off-by: Jorgen Hansen <jhansen at vmware.com> ---

If a server side socket is bound to an address, but not in the listening state yet, incoming connection requests should receive a reset control packet in response. However, the function used to send the reset silently drops the reset packet if the sending socket isn't bound to a remote address (as is the case for a bound socket not yet in the listening state). This change fixes this by using

Most of the patches are reviewed by Dexuan, Stefan, and Jorgen. The following patches need reviews: - [11/15] vsock: add multi-transports support - [12/15] vsock/vmci: register vmci_transport only when VMCI guest/host are active - [15/15] vhost/vsock: refuse CID assigned to the guest->host transport RFC: https://patchwork.ozlabs.org/cover/1168442/ v1:

All transports call __vsock_create() with the same parameters, most of them depending on the parent socket. In order to simplify the VSOCK core APIs exposed to the transports, this patch adds the vsock_create_connected() callable from transports to create a new socket when a connection request is received. We also unexported the __vsock_create(). Suggested-by: Stefan Hajnoczi <stefanha at

This series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html 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. Before this series, vmci-transport supported this behavior but only using VMware

This series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html 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. Before this series, vmci-transport supported this behavior but only using VMware

vmci_transport never allowed half-closed socket on the host side. Since we want to have the same behaviour across all transports, we add a section in the "Implementation notes". Cc: Jorgen Hansen <jhansen at vmware.com> Cc: Adit Ranadive <aditr at vmware.com> Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- net/vmw_vsock/af_vsock.c | 4 ++++ 1 file