Received: by 10.192.165.156 with SMTP id m28csp1157561imm; Wed, 11 Apr 2018 13:32:14 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+XqaVaP8B29Srqws+QJD2uaOf1byy5xECIIrXuoPW3mx5fXFUXKEI+9UWbdJNZFI7dkoup X-Received: by 2002:a17:902:bcc5:: with SMTP id o5-v6mr6753996pls.179.1523478734033; Wed, 11 Apr 2018 13:32:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523478734; cv=none; d=google.com; s=arc-20160816; b=oUCTQEDrqMolGsdYYOIB1Csv9QgKtIEAIHaL5ObaK2jNou8dxPENTjI2ARj99OWkH+ UOdm1B2WrNTsZOAcNd+2PDKlf5fDc+RTFnfdRUgRMtUsUJm5Jfx1fOYBQkI+RLgTGzeL u7M7nAxnfuuvGZFMnMFvNQlySB0ijiz6EkZCiy4NPTAi20plB5fO0dD1O6fRhmy5/bqs 4639mesd9BftNkXwNlzv/1sJ3RQWxY/Ns5vkhPcFNwWTu4hhBO/bai3i4lDM/Jp2UXSb JGsBAcY3sVvWaImqX1/FQQAlrQ1U8C/U5g1/tNjlNYTeKlKDgb+nhCtcdq9/PLcQZZYu 71Eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=BW9wv8SOZi+RxkanYO6iDsjQ0v0MLHtBMyPL+RM8s5U=; b=ONRQwYu63Yv6jAc6Ry76AgGqBc10Kdo8/sudRH76+rl6jdgdAK4mj/PtASMwOSXae7 CXXGs74FDHx/Qp78cT5otjR8aRN+k78boQFxOUKswWhw4JVbezWyoosxLOr71Upd0Pka RzBJQxNO1tCJzIZMkgfNH6GKJkea87DwvZrPelhYK2pFErBXERVkUzjmrsHIRGTGjwr0 cT5RVjrHoUWzOBoia/oCQXYfBnpsXJK/IVG2akViLXbVg1yAHS9a6Vwb7cz83XBF/Tgm nLEIFhjeJjXrNrDX/AszHGkNPOiTUdQhmOCQLjL6qS+sqmpN6JOyA15u6TarwyjTSKmQ 2fsA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p20-v6si1825941plo.284.2018.04.11.13.31.37; Wed, 11 Apr 2018 13:32:13 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932875AbeDKSvb (ORCPT + 99 others); Wed, 11 Apr 2018 14:51:31 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:33044 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932834AbeDKSv1 (ORCPT ); Wed, 11 Apr 2018 14:51:27 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 31922D72; Wed, 11 Apr 2018 18:51:27 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dmitry Vyukov , Marcelo Ricardo Leitner , Cong Wang , Xin Long , "David S. Miller" , Sasha Levin Subject: [PATCH 4.4 140/190] sctp: fix recursive locking warning in sctp_do_peeloff Date: Wed, 11 Apr 2018 20:36:26 +0200 Message-Id: <20180411183600.791413624@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180411183550.114495991@linuxfoundation.org> References: <20180411183550.114495991@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Xin Long [ Upstream commit 6dfe4b97e08ec3d1a593fdaca099f0ef0a3a19e6 ] Dmitry got the following recursive locking report while running syzkaller fuzzer, the Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0x2ee/0x3ef lib/dump_stack.c:52 print_deadlock_bug kernel/locking/lockdep.c:1729 [inline] check_deadlock kernel/locking/lockdep.c:1773 [inline] validate_chain kernel/locking/lockdep.c:2251 [inline] __lock_acquire+0xef2/0x3430 kernel/locking/lockdep.c:3340 lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755 lock_sock_nested+0xcb/0x120 net/core/sock.c:2536 lock_sock include/net/sock.h:1460 [inline] sctp_close+0xcd/0x9d0 net/sctp/socket.c:1497 inet_release+0xed/0x1c0 net/ipv4/af_inet.c:425 inet6_release+0x50/0x70 net/ipv6/af_inet6.c:432 sock_release+0x8d/0x1e0 net/socket.c:597 __sock_create+0x38b/0x870 net/socket.c:1226 sock_create+0x7f/0xa0 net/socket.c:1237 sctp_do_peeloff+0x1a2/0x440 net/sctp/socket.c:4879 sctp_getsockopt_peeloff net/sctp/socket.c:4914 [inline] sctp_getsockopt+0x111a/0x67e0 net/sctp/socket.c:6628 sock_common_getsockopt+0x95/0xd0 net/core/sock.c:2690 SYSC_getsockopt net/socket.c:1817 [inline] SyS_getsockopt+0x240/0x380 net/socket.c:1799 entry_SYSCALL_64_fastpath+0x1f/0xc2 This warning is caused by the lock held by sctp_getsockopt() is on one socket, while the other lock that sctp_close() is getting later is on the newly created (which failed) socket during peeloff operation. This patch is to avoid this warning by use lock_sock with subclass SINGLE_DEPTH_NESTING as Wang Cong and Marcelo's suggestion. Reported-by: Dmitry Vyukov Suggested-by: Marcelo Ricardo Leitner Suggested-by: Cong Wang Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- net/sctp/socket.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -1518,7 +1518,7 @@ static void sctp_close(struct sock *sk, pr_debug("%s: sk:%p, timeout:%ld\n", __func__, sk, timeout); - lock_sock(sk); + lock_sock_nested(sk, SINGLE_DEPTH_NESTING); sk->sk_shutdown = SHUTDOWN_MASK; sk->sk_state = SCTP_SS_CLOSING; @@ -1569,7 +1569,7 @@ static void sctp_close(struct sock *sk, * held and that should be grabbed before socket lock. */ spin_lock_bh(&net->sctp.addr_wq_lock); - bh_lock_sock(sk); + bh_lock_sock_nested(sk); /* Hold the sock, since sk_common_release() will put sock_put() * and we have just a little more cleanup.