lkml.org 
[lkml]   [2021]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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:
> >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!

\
 
 \ /
  Last update: 2021-08-12 20:00    [W:0.035 / U:0.852 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site