Patch "vsock/virtio: avoid potential deadlock when vsock device remove" has been added to the 5.13-stable tree

[Sasha Levin <sashal@xxxxxxxxxx>]

This is a note to let you know that I've just added the patch titled

    vsock/virtio: avoid potential deadlock when vsock device remove

to the 5.13-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:
     vsock-virtio-avoid-potential-deadlock-when-vsock-dev.patch
and it can be found in the queue-5.13 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 31db097ff6f7c0b31568ce58982f6fc51dfbebe7
Author: Longpeng(Mike) <longpeng2@xxxxxxxxxx>
Date:   Thu Aug 12 13:30:56 2021 +0800

    vsock/virtio: avoid potential deadlock when vsock device remove
    
    [ Upstream commit 49b0b6ffe20c5344f4173f3436298782a08da4f2 ]
    
    There's a potential deadlock case when remove the vsock device or
    process the RESET event:
    
      vsock_for_each_connected_socket:
          spin_lock_bh(&vsock_table_lock) ----------- (1)
          ...
              virtio_vsock_reset_sock:
                  lock_sock(sk) --------------------- (2)
          ...
          spin_unlock_bh(&vsock_table_lock)
    
    lock_sock() may do initiative schedule when the 'sk' is owned by
    other thread at the same time, we would receivce a warning message
    that "scheduling while atomic".
    
    Even worse, if the next task (selected by the scheduler) try to
    release a 'sk', it need to request vsock_table_lock and the deadlock
    occur, cause the system into softlockup state.
      Call trace:
       queued_spin_lock_slowpath
       vsock_remove_bound
       vsock_remove_sock
       virtio_transport_release
       __vsock_release
       vsock_release
       __sock_release
       sock_close
       __fput
       ____fput
    
    So we should not require sk_lock in this case, just like the behavior
    in vhost_vsock or vmci.
    
    Fixes: 0ea9e1d3a9e3 ("VSOCK: Introduce virtio_transport.ko")
    Cc: Stefan Hajnoczi <stefanha@xxxxxxxxxx>
    Signed-off-by: Longpeng(Mike) <longpeng2@xxxxxxxxxx>
    Reviewed-by: Stefano Garzarella <sgarzare@xxxxxxxxxx>
    Link: https://lore.kernel.org/r/20210812053056.1699-1-longpeng2@xxxxxxxxxx
    Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
index 2700a63ab095..3a056f8affd1 100644
--- a/net/vmw_vsock/virtio_transport.c
+++ b/net/vmw_vsock/virtio_transport.c
@@ -356,11 +356,14 @@ static void virtio_vsock_event_fill(struct virtio_vsock *vsock)
 
 static void virtio_vsock_reset_sock(struct sock *sk)
 {
-	lock_sock(sk);
+	/* vmci_transport.c doesn't take sk_lock here either.  At least we're
+	 * under vsock_table_lock so the sock cannot disappear while we're
+	 * executing.
+	 */
+
 	sk->sk_state = TCP_CLOSE;
 	sk->sk_err = ECONNRESET;
 	sk->sk_error_report(sk);
-	release_sock(sk);
 }
 
 static void virtio_vsock_update_guest_cid(struct virtio_vsock *vsock)