From: Hillf Danton <hdanton@sina.com>
To: Stefano Garzarella <sgarzare@redhat.com>
Cc: kvm@vger.kernel.org,
syzbot <syzbot+731710996d79d0d58fbc@syzkaller.appspotmail.com>,
netdev@vger.kernel.org, Dexuan Cui <decui@microsoft.com>,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
syzkaller-bugs@googlegroups.com,
Stefan Hajnoczi <stefanha@redhat.com>,
kuba@kernel.org, davem@davemloft.net,
Jorgen Hansen <jhansen@vmware.com>
Subject: Re: INFO: task hung in lock_sock_nested (2)
Date: Mon, 24 Feb 2020 21:44:28 +0800 [thread overview]
Message-ID: <20200224134428.12256-1-hdanton@sina.com> (raw)
In-Reply-To: <20200223075025.9068-1-hdanton@sina.com>
On Mon, 24 Feb 2020 11:08:53 +0100 Stefano Garzarella wrote:
> On Sun, Feb 23, 2020 at 03:50:25PM +0800, Hillf Danton wrote:
> >
> > Seems like vsock needs a word to track lock owner in an attempt to
> > avoid trying to lock sock while the current is the lock owner.
>
> Thanks for this possible solution.
> What about using sock_owned_by_user()?
>
No chance for vsock_locked() if it works.
> We should fix also hyperv_transport, because it could suffer from the same
> problem.
>
You're right. My diff is at most for introducing vsk's lock owner.
> At this point, it might be better to call vsk->transport->release(vsk)
> always with the lock taken and remove it in the transports as in the
> following patch.
>
> What do you think?
>
Yes and ... please take a look at the output of grep
grep -n lock_sock linux/net/vmw_vsock/af_vsock.c
as it drove me mad.
>
> diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
> index 9c5b2a91baad..a073d8efca33 100644
> --- a/net/vmw_vsock/af_vsock.c
> +++ b/net/vmw_vsock/af_vsock.c
> @@ -753,20 +753,18 @@ static void __vsock_release(struct sock *sk, int level)
> vsk = vsock_sk(sk);
> pending = NULL; /* Compiler warning. */
>
> - /* The release call is supposed to use lock_sock_nested()
> - * rather than lock_sock(), if a sock lock should be acquired.
> - */
> - if (vsk->transport)
> - vsk->transport->release(vsk);
> - else if (sk->sk_type == SOCK_STREAM)
> - vsock_remove_sock(vsk);
> -
> /* When "level" is SINGLE_DEPTH_NESTING, use the nested
> * version to avoid the warning "possible recursive locking
> * detected". When "level" is 0, lock_sock_nested(sk, level)
> * is the same as lock_sock(sk).
> */
> lock_sock_nested(sk, level);
> +
> + if (vsk->transport)
> + vsk->transport->release(vsk);
> + else if (sk->sk_type == SOCK_STREAM)
> + vsock_remove_sock(vsk);
> +
> sock_orphan(sk);
> sk->sk_shutdown = SHUTDOWN_MASK;
>
> diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
> index 3492c021925f..510f25f4a856 100644
> --- a/net/vmw_vsock/hyperv_transport.c
> +++ b/net/vmw_vsock/hyperv_transport.c
> @@ -529,9 +529,7 @@ static void hvs_release(struct vsock_sock *vsk)
> struct sock *sk = sk_vsock(vsk);
> bool remove_sock;
>
> - lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
> remove_sock = hvs_close_lock_held(vsk);
> - release_sock(sk);
> if (remove_sock)
> vsock_remove_sock(vsk);
> }
> diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
> index d9f0c9c5425a..f3c4bab2f737 100644
> --- a/net/vmw_vsock/virtio_transport_common.c
> +++ b/net/vmw_vsock/virtio_transport_common.c
> @@ -829,7 +829,6 @@ void virtio_transport_release(struct vsock_sock *vsk)
> struct sock *sk = &vsk->sk;
> bool remove_sock = true;
>
> - lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
> if (sk->sk_type == SOCK_STREAM)
> remove_sock = virtio_transport_close(vsk);
>
> @@ -837,7 +836,6 @@ void virtio_transport_release(struct vsock_sock *vsk)
> list_del(&pkt->list);
> virtio_transport_free_pkt(pkt);
> }
> - release_sock(sk);
>
> if (remove_sock)
> vsock_remove_sock(vsk);
>
> Thanks,
> Stefano
next prev parent reply other threads:[~2020-02-24 13:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-22 18:58 INFO: task hung in lock_sock_nested (2) syzbot
2020-02-23 7:50 ` Hillf Danton
2020-02-24 10:08 ` Stefano Garzarella
2020-02-25 5:44 ` Dexuan Cui
2020-02-25 8:30 ` Stefano Garzarella
2020-02-24 13:44 ` Hillf Danton [this message]
2020-02-25 9:07 ` Stefano Garzarella
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200224134428.12256-1-hdanton@sina.com \
--to=hdanton@sina.com \
--cc=davem@davemloft.net \
--cc=decui@microsoft.com \
--cc=jhansen@vmware.com \
--cc=kuba@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sgarzare@redhat.com \
--cc=stefanha@redhat.com \
--cc=syzbot+731710996d79d0d58fbc@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).