Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp1289110ybf; Thu, 27 Feb 2020 08:11:37 -0800 (PST) X-Google-Smtp-Source: APXvYqxfENY1Qr9SPZa4L1faDoOSSZNgPUM8ZfasBCdjdFPMy37XMiGp+HXW9LfIJiWV9p7Z61OW X-Received: by 2002:a54:4106:: with SMTP id l6mr3913093oic.76.1582819897050; Thu, 27 Feb 2020 08:11:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582819897; cv=none; d=google.com; s=arc-20160816; b=QV5bNUX+3UxA9Xz/TKJ4+MyOyntyKm+fMuj2CiXq4rr9v+Dk3SLxW4wFsMjSiJznRg FCuciWDK7cdF6q+0jBaWt7RiQCtxsAXxz41kikDEb0+RAu0hECLt+ZoZm+ooLZLnjDiS eEhEfONNz+fIGsDiduHG2LMeRv5OguW9tLir8Quafb3CWnGAV5+nTQDaXK8QxteYagNu XsgkenN75BOBq8IkcUhjv6XoVs90iFIfMINmSL/mcHE5gH+8X7HIxqK7cUPIN4lcy2Tm zzy/7O05P9WVpT9fugNYJ8xdX5m+/whTSjXILnDraJu/nmaOmFd+EFB199zsn2w55MLq aY4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-disposition:in-reply-to :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=baOVStFi/SNG29sbg/ucY09+VCW+eczt7xzz7SmVLS4=; b=HXGhIcsjO+HbL2oK39wP3aBzSkVKgUvws30AWxpL4FmZi3JfMUNLFLJfsKWjzAJ1kj OCBPovQqNylNPpnoQg4qO+uLTbUy5NMyDySsJzoCKuRI3bHLiy4pQ4/HegVgy9ZKBz16 FSCK/feLI/PycNZYTda8Oz3U8iNwU8qN/jgxRYd6eF8Gxe5BlLvE/IJy+tbRQRVaUkBK zn4IH2kz0WxIIdjEW9QWbxA1XkoOCQE/0fO3k23tHneKLjARyXhzK+OpiFqWDiwG7z8+ XWU3nUUd0gRDYgqUf5d101dR/J90JJZtrR+1/RVIN6G7hHdZvB3a4MTKEUmt+MnkbCPB Dg6g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="D5/70dFj"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s15si74323oih.252.2020.02.27.08.11.24; Thu, 27 Feb 2020 08:11:37 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="D5/70dFj"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729893AbgB0QLO (ORCPT + 99 others); Thu, 27 Feb 2020 11:11:14 -0500 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:20440 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729443AbgB0QLN (ORCPT ); Thu, 27 Feb 2020 11:11:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582819873; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=baOVStFi/SNG29sbg/ucY09+VCW+eczt7xzz7SmVLS4=; b=D5/70dFjBGR1x6K5TCDK/j+zZ1AHpRfnyzfwVsjw4koT2Za7Z2dlwBeyu5IYwYL6u3eMhE mGXNts2lo5+M9Dfggmhgwa9Cq1r0/LNhrftIcbLugkbF38AdcKqE6zl+va2KiYD3nPB552 mx49TdHmEfqKhRUPRoZl4E59Z39Xh5k= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-225-5nDBex09N9-vClpZCVygwA-1; Thu, 27 Feb 2020 11:11:08 -0500 X-MC-Unique: 5nDBex09N9-vClpZCVygwA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6D43FDB68; Thu, 27 Feb 2020 16:11:05 +0000 (UTC) Received: from localhost (ovpn-117-38.ams2.redhat.com [10.36.117.38]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2EE2760C63; Thu, 27 Feb 2020 16:11:03 +0000 (UTC) Date: Thu, 27 Feb 2020 16:11:02 +0000 From: Stefan Hajnoczi To: Stefano Garzarella Cc: davem@davemloft.net, Dexuan Cui , Hillf Danton , virtualization@lists.linux-foundation.org, "K. Y. Srinivasan" , kvm@vger.kernel.org, Stephen Hemminger , syzbot+731710996d79d0d58fbc@syzkaller.appspotmail.com, netdev@vger.kernel.org, Sasha Levin , Sunil Muthuswamy , linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, Jakub Kicinski , Haiyang Zhang , Jorgen Hansen Subject: Re: [PATCH net] vsock: fix potential deadlock in transport->release() Message-ID: <20200227161102.GC315098@stefanha-x1.localdomain> References: <20200226105818.36055-1-sgarzare@redhat.com> MIME-Version: 1.0 In-Reply-To: <20200226105818.36055-1-sgarzare@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DIOMP1UsTsWJauNi" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --DIOMP1UsTsWJauNi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 26, 2020 at 11:58:18AM +0100, Stefano Garzarella wrote: > Some transports (hyperv, virtio) acquire the sock lock during the > .release() callback. >=20 > In the vsock_stream_connect() we call vsock_assign_transport(); if > the socket was previously assigned to another transport, the > vsk->transport->release() is called, but the sock lock is already > held in the vsock_stream_connect(), causing a deadlock reported by > syzbot: >=20 > INFO: task syz-executor280:9768 blocked for more than 143 seconds. > Not tainted 5.6.0-rc1-syzkaller #0 > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this mess= age. > syz-executor280 D27912 9768 9766 0x00000000 > Call Trace: > context_switch kernel/sched/core.c:3386 [inline] > __schedule+0x934/0x1f90 kernel/sched/core.c:4082 > schedule+0xdc/0x2b0 kernel/sched/core.c:4156 > __lock_sock+0x165/0x290 net/core/sock.c:2413 > lock_sock_nested+0xfe/0x120 net/core/sock.c:2938 > virtio_transport_release+0xc4/0xd60 net/vmw_vsock/virtio_transport_c= ommon.c:832 > vsock_assign_transport+0xf3/0x3b0 net/vmw_vsock/af_vsock.c:454 > vsock_stream_connect+0x2b3/0xc70 net/vmw_vsock/af_vsock.c:1288 > __sys_connect_file+0x161/0x1c0 net/socket.c:1857 > __sys_connect+0x174/0x1b0 net/socket.c:1874 > __do_sys_connect net/socket.c:1885 [inline] > __se_sys_connect net/socket.c:1882 [inline] > __x64_sys_connect+0x73/0xb0 net/socket.c:1882 > do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 > entry_SYSCALL_64_after_hwframe+0x49/0xbe >=20 > To avoid this issue, this patch remove the lock acquiring in the > .release() callback of hyperv and virtio transports, and it holds > the lock when we call vsk->transport->release() in the vsock core. >=20 > Reported-by: syzbot+731710996d79d0d58fbc@syzkaller.appspotmail.com > Fixes: 408624af4c89 ("vsock: use local transport when it is loaded") > Signed-off-by: Stefano Garzarella > --- > net/vmw_vsock/af_vsock.c | 20 ++++++++++++-------- > net/vmw_vsock/hyperv_transport.c | 3 --- > net/vmw_vsock/virtio_transport_common.c | 2 -- > 3 files changed, 12 insertions(+), 13 deletions(-) Reviewed-by: Stefan Hajnoczi --DIOMP1UsTsWJauNi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAl5X6hYACgkQnKSrs4Gr c8hIwwf/VpB7q37vIv4l2+NFuq3CWGZbLfSSG7A9u4sXSo+VhcEltqh8jdz8xEfS k9JaAaCosM43HAtz+LPmfHG6eL761HjpUQ9KnLgU53aWhJwFuIv000o2w+OA3X4O cr1aWzcWJzFpkU1xQb41J1FR8FUymgWSqQPitEF3ElEnmbfFGSrEgrVOc9Ou2Qhb 57r4rlPuiZNNshiWMjCalPewQeJETnrEnB9cxsjc0gMu/xn1KRE7g6i4yG1smtjm YSgZmV1NgDWrAKr//amiOCqTvKH2DUYYgvUwnx27G0iRrWO47TQYbE+/jDd+FUol u2jPzVcR0q/qq1CJsyPqKx+7pdCqUg== =t+mC -----END PGP SIGNATURE----- --DIOMP1UsTsWJauNi--