From 448efe512db461208c82e8dddf3baa61ecb15d3c Mon Sep 17 00:00:00 2001 From: Jose Carlos Venegas Munoz Date: Wed, 13 May 2020 15:06:04 +0000 Subject: [PATCH] sock: Add mising fix to experimental kernel Cloud hypervisor uses vsock, without this patch CI for cloud hypervisor is not stable. Patch information: ``` There was a race condition between bind() and listen() that was hit very rarely when using Kata Containers and Cloud-Hypervisor. It's been identified the problem is really coming from the virtio-vsock driver, which is fixed by those new kernel patches uploaded for each version of the kernels used by Kata Containers. ``` Update: Fixed to make it build with kernel 5.6 Fixes #932 Signed-off-by: Jose Carlos Venegas Munoz --- kernel/kata_config_version | 2 +- ...-Fix-race-condition-between-bind-and.patch | 49 +++++++++++++++++++ 2 files changed, 50 insertions(+), 1 deletion(-) create mode 100644 kernel/patches/virtio-fs-dev.virtio-fs-dev.x/0001-net-virtio_vsock-Fix-race-condition-between-bind-and.patch diff --git a/kernel/kata_config_version b/kernel/kata_config_version index 987e7ca9a..8e14edce9 100644 --- a/kernel/kata_config_version +++ b/kernel/kata_config_version @@ -1 +1 @@ -77 +78 diff --git a/kernel/patches/virtio-fs-dev.virtio-fs-dev.x/0001-net-virtio_vsock-Fix-race-condition-between-bind-and.patch b/kernel/patches/virtio-fs-dev.virtio-fs-dev.x/0001-net-virtio_vsock-Fix-race-condition-between-bind-and.patch new file mode 100644 index 000000000..bb15836fa --- /dev/null +++ b/kernel/patches/virtio-fs-dev.virtio-fs-dev.x/0001-net-virtio_vsock-Fix-race-condition-between-bind-and.patch @@ -0,0 +1,49 @@ +From c7ec155ec5e0f573e9c3cc4eb38d47543a2f1e81 Mon Sep 17 00:00:00 2001 +From: Sebastien Boeuf +Date: Thu, 13 Feb 2020 08:50:38 +0100 +Subject: [PATCH] net: virtio_vsock: Fix race condition between bind and listen + +Whenever the vsock backend on the host sends a packet through the RX +queue, it expects an answer on the TX queue. Unfortunately, there is one +case where the host side will hang waiting for the answer and will +effectively never recover. + +This issue happens when the guest side starts binding to the socket, +which insert a new bound socket into the list of already bound sockets. +At this time, we expect the guest to also start listening, which will +trigger the sk_state to move from TCP_CLOSE to TCP_LISTEN. The problem +occurs if the host side queued a RX packet and triggered an interrupt +right between the end of the binding process and the beginning of the +listening process. In this specific case, the function processing the +packet virtio_transport_recv_pkt() will find a bound socket, which means +it will hit the switch statement checking for the sk_state, but the +state won't be changed into TCP_LISTEN yet, which leads the code to pick +the default statement. This default statement will only free the buffer, +while it should also respond to the host side, by sending a packet on +its TX queue. + +In order to simply fix this unfortunate chain of events, it is important +that in case the default statement is entered, and because at this stage +we know the host side is waiting for an answer, we must send back a +packet containing the operation VIRTIO_VSOCK_OP_RST. + +Signed-off-by: Sebastien Boeuf +--- + net/vmw_vsock/virtio_transport_common.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c +index 6f1a8aff65c5..0b6fb687a3e0 100644 +--- a/net/vmw_vsock/virtio_transport_common.c ++++ b/net/vmw_vsock/virtio_transport_common.c +@@ -1048,6 +1048,7 @@ void virtio_transport_recv_pkt(struct virtio_vsock_pkt *pkt) + virtio_transport_free_pkt(pkt); + break; + default: ++ (void)virtio_transport_reset_no_sock(t, pkt); + virtio_transport_free_pkt(pkt); + break; + } +-- +2.20.1 +