lkml.org 
[lkml]   [2020]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Patch "net: virtio_vsock: Enhance connection semantics" has been added to the 4.9-stable tree
On Fri, Oct 02, 2020 at 07:18:20PM -0400, Sasha Levin wrote:
> This is a note to let you know that I've just added the patch titled
>
> net: virtio_vsock: Enhance connection semantics
>
> to the 4.9-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>
> The filename of the patch is:
> net-virtio_vsock-enhance-connection-semantics.patch
> and it can be found in the queue-4.9 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable@vger.kernel.org> know about it.
>
>
>
> commit 298b295d45688ac79bebe2e87efa96711e2e0bad
> Author: Sebastien Boeuf <sebastien.boeuf@intel.com>
> Date: Fri Feb 14 12:48:01 2020 +0100
>
> net: virtio_vsock: Enhance connection semantics
>
> [ Upstream commit df12eb6d6cd920ab2f0e0a43cd6e1c23a05cea91 ]
>
> 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 might
> effectively never recover if no timeout mechanism was implemented.
>
> 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.
>
> One could say that a proper timeout mechanism on the host side will be
> enough to avoid the backend to hang. But the point of this patch is to
> ensure the normal use case will be provided with proper responsiveness
> when it comes to establishing the connection.
>
> Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
>
> diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
> index d64285afe68f3..f66bd0510f138 100644
> --- a/net/vmw_vsock/virtio_transport_common.c
> +++ b/net/vmw_vsock/virtio_transport_common.c
> @@ -986,6 +986,7 @@ void virtio_transport_recv_pkt(struct virtio_transport *t,
> virtio_transport_free_pkt(pkt);
> break;
> default:
> + (void)virtio_transport_reset_no_sock(t, pkt);
> virtio_transport_free_pkt(pkt);
> break;
> }


Also breaks the build on 4.9, so dropping it.

greg k-h

\
 
 \ /
  Last update: 2020-10-03 16:43    [W:0.030 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site