5.6-stable patches

added patches:
	vhost-vsock-kick-send_pkt-worker-once-device-is-started.patch

diff --git a/queue-5.6/vhost-vsock-kick-send_pkt-worker-once-device-is-started.patch b/queue-5.6/vhost-vsock-kick-send_pkt-worker-once-device-is-started.patch
new file mode 100644 (file)
index 0000000..9726682
--- /dev/null
+++ b/queue-5.6/vhost-vsock-kick-send_pkt-worker-once-device-is-started.patch
@@ -0,0 +1,72 @@
+From 0b841030625cde5f784dd62aec72d6a766faae70 Mon Sep 17 00:00:00 2001
+From: Jia He <justin.he@arm.com>
+Date: Fri, 1 May 2020 12:38:40 +0800
+Subject: vhost: vsock: kick send_pkt worker once device is started
+
+From: Jia He <justin.he@arm.com>
+
+commit 0b841030625cde5f784dd62aec72d6a766faae70 upstream.
+
+Ning Bo reported an abnormal 2-second gap when booting Kata container [1].
+The unconditional timeout was caused by VSOCK_DEFAULT_CONNECT_TIMEOUT of
+connecting from the client side. The vhost vsock client tries to connect
+an initializing virtio vsock server.
+
+The abnormal flow looks like:
+host-userspace           vhost vsock                       guest vsock
+==============           ===========                       ============
+connect()     -------->  vhost_transport_send_pkt_work()   initializing
+   |                     vq->private_data==NULL
+   |                     will not be queued
+   V
+schedule_timeout(2s)
+                         vhost_vsock_start()  <---------   device ready
+                         set vq->private_data
+
+wait for 2s and failed
+connect() again          vq->private_data!=NULL         recv connecting pkt
+
+Details:
+1. Host userspace sends a connect pkt, at that time, guest vsock is under
+   initializing, hence the vhost_vsock_start has not been called. So
+   vq->private_data==NULL, and the pkt is not been queued to send to guest
+2. Then it sleeps for 2s
+3. After guest vsock finishes initializing, vq->private_data is set
+4. When host userspace wakes up after 2s, send connecting pkt again,
+   everything is fine.
+
+As suggested by Stefano Garzarella, this fixes it by additional kicking the
+send_pkt worker in vhost_vsock_start once the virtio device is started. This
+makes the pending pkt sent again.
+
+After this patch, kata-runtime (with vsock enabled) boot time is reduced
+from 3s to 1s on a ThunderX2 arm64 server.
+
+[1] https://github.com/kata-containers/runtime/issues/1917
+
+Reported-by: Ning Bo <n.b@live.com>
+Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
+Signed-off-by: Jia He <justin.he@arm.com>
+Link: https://lore.kernel.org/r/20200501043840.186557-1-justin.he@arm.com
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/vhost/vsock.c |    5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/vhost/vsock.c
++++ b/drivers/vhost/vsock.c
+@@ -543,6 +543,11 @@ static int vhost_vsock_start(struct vhos
+               mutex_unlock(&vq->mutex);
+       }
+ 
++      /* Some packets may have been queued before the device was started,
++       * let's kick the send worker to send them.
++       */
++      vhost_work_queue(&vsock->dev, &vsock->send_pkt_work);
++
+       mutex_unlock(&vsock->dev.mutex);
+       return 0;
+