similar to: [PATCH v3] vsock/virtio: free packets during the socket release

When the socket is released, we should free all packets queued in the per-socket list in order to avoid a memory leak. Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- net/vmw_vsock/virtio_transport_common.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c index

On Mon, Sep 30, 2019 at 06:43:50PM +0000, Dexuan Cui wrote: > Lockdep is unhappy if two locks from the same class are held. > > Fix the below warning for hyperv and virtio sockets (vmci socket code > doesn't have the issue) by using lock_sock_nested() when __vsock_release() > is called recursively: > > ============================================ > WARNING: possible

From: Stefano Garzarella <sgarzare at redhat.com> Date: Fri, 10 May 2019 14:58:37 +0200 > @@ -827,12 +827,20 @@ static bool virtio_transport_close(struct vsock_sock *vsk) > > void virtio_transport_release(struct vsock_sock *vsk) > { > + struct virtio_vsock_sock *vvs = vsk->trans; > + struct virtio_vsock_buf *buf; > struct sock *sk = &vsk->sk; > bool

Hi Dexuan, On Thu, Sep 26, 2019 at 01:11:27AM +0000, Dexuan Cui wrote: > Lockdep is unhappy if two locks from the same class are held. > > Fix the below warning for hyperv and virtio sockets (vmci socket code > doesn't have the issue) by using lock_sock_nested() when __vsock_release() > is called recursively: > > ============================================ >

Since virtio-vsock was introduced, the buffers filled by the host and pushed to the guest using the vring, are directly queued in a per-socket list. These buffers are preallocated by the guest with a fixed size (4 KB). The maximum amount of memory used by each socket should be controlled by the credit mechanism. The default credit available per-socket is 256 KB, but if we use only 1 byte per

In order to reduce the number of credit update messages, we send them only when the space available seen by the transmitter is less than VIRTIO_VSOCK_MAX_PKT_BUF_SIZE. Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- include/linux/virtio_vsock.h | 1 + net/vmw_vsock/virtio_transport_common.c | 14 +++++++++++--- 2 files changed, 12 insertions(+), 3 deletions(-)

On Wed, Oct 09, 2019 at 01:30:26PM +0100, Stefan Hajnoczi wrote: > On Fri, Sep 27, 2019 at 01:26:57PM +0200, Stefano Garzarella wrote: > > @@ -140,18 +145,11 @@ struct vsock_transport { > > struct vsock_transport_send_notify_data *); > > int (*notify_send_post_enqueue)(struct vsock_sock *, ssize_t, > > struct vsock_transport_send_notify_data *); > > + int

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

On Fri, May 10, 2019 at 02:58:36PM +0200, Stefano Garzarella wrote: > Since virtio-vsock was introduced, the buffers filled by the host > and pushed to the guest using the vring, are directly queued in > a per-socket list avoiding to copy it. > These buffers are preallocated by the guest with a fixed > size (4 KB). > > The maximum amount of memory used by each socket should

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/5/10 ??8:58, Stefano Garzarella wrote: > Since virtio-vsock was introduced, the buffers filled by the host > and pushed to the guest using the vring, are directly queued in > a per-socket list avoiding to copy it. > These buffers are preallocated by the guest with a fixed > size (4 KB). > > The maximum amount of memory used by each socket should be > controlled by

On 2019/5/10 ??8:58, Stefano Garzarella wrote: > Since virtio-vsock was introduced, the buffers filled by the host > and pushed to the guest using the vring, are directly queued in > a per-socket list avoiding to copy it. > These buffers are preallocated by the guest with a fixed > size (4 KB). > > The maximum amount of memory used by each socket should be > controlled by

Since virtio-vsock was introduced, the buffers filled by the host and pushed to the guest using the vring, are directly queued in a per-socket list avoiding to copy it. These buffers are preallocated by the guest with a fixed size (4 KB). The maximum amount of memory used by each socket should be controlled by the credit mechanism. The default credit available per-socket is 256 KB, but if we use

virtio_transport and vmci_transport handle the buffer_size sockopts in a very similar way. In order to support multiple transports, this patch moves this handling in the core to allow the user to change the options also if the socket is not yet assigned to any transport. This patch also adds the '.notify_buffer_size' callback in the 'struct virtio_transport' in order to inform

virtio_transport and vmci_transport handle the buffer_size sockopts in a very similar way. In order to support multiple transports, this patch moves this handling in the core to allow the user to change the options also if the socket is not yet assigned to any transport. This patch also adds the '.notify_buffer_size' callback in the 'struct virtio_transport' in order to inform

On Fri, Sep 27, 2019 at 01:26:57PM +0200, Stefano Garzarella wrote: > @@ -140,18 +145,11 @@ struct vsock_transport { > struct vsock_transport_send_notify_data *); > int (*notify_send_post_enqueue)(struct vsock_sock *, ssize_t, > struct vsock_transport_send_notify_data *); > + int (*notify_buffer_size)(struct vsock_sock *, u64 *); Is ->notify_buffer_size() called under

On Fri, Sep 27, 2019 at 01:26:57PM +0200, Stefano Garzarella wrote: > @@ -140,18 +145,11 @@ struct vsock_transport { > struct vsock_transport_send_notify_data *); > int (*notify_send_post_enqueue)(struct vsock_sock *, ssize_t, > struct vsock_transport_send_notify_data *); > + int (*notify_buffer_size)(struct vsock_sock *, u64 *); Is ->notify_buffer_size() called under

> From: Stefano Garzarella [mailto:sgarzare at redhat.com] > Sent: Wednesday, October 23, 2019 11:56 AM > Subject: [PATCH net-next 07/14] vsock: handle buffer_size sockopts in the > core > > virtio_transport and vmci_transport handle the buffer_size sockopts in a > very similar way. > > In order to support multiple transports, this patch moves this handling in the >

Otherwise we'll leave the packets queued until releasing vsock device. E.g., if guest is slow to start up, resulting ETIMEDOUT on connect, guest will get the connect requests from failed host sockets. Signed-off-by: Peng Tao <bergwolf at gmail.com> --- include/linux/virtio_vsock.h | 7 +++++++ net/vmw_vsock/af_vsock.c | 7 +++++++

Otherwise we'll leave the packets queued until releasing vsock device. E.g., if guest is slow to start up, resulting ETIMEDOUT on connect, guest will get the connect requests from failed host sockets. Reviewed-by: Stefan Hajnoczi <stefanha at redhat.com> Signed-off-by: Peng Tao <bergwolf at gmail.com> --- include/linux/virtio_vsock.h | 7 +++++++