Re: [PATCH resend] vsock/virtio: avoid potential deadlock when vsock device remove

On Thu, 12 Aug 2021 10:03:32 +0200 Stefano Garzarella wrote:

On Thu, Aug 12, 2021 at 01:30:56PM +0800, Longpeng(Mike) wrote:

quoted

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.  

We should add:
Fixes: 0ea9e1d3a9e3 ("VSOCK: Introduce virtio_transport.ko")

Added.

Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>

And applied, thanks!