From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Westphal Subject: Re: possible deadlock in rtnl_lock (5) Date: Tue, 27 Mar 2018 13:50:01 +0200 Message-ID: <20180327115001.GC26275@breakpoint.cc> References: <000000000000f7826f0568630354@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netdev@vger.kernel.org, syzkaller-bugs@googlegroups.com, ja@ssi.bg To: syzbot Return-path: Received: from Chamillionaire.breakpoint.cc ([146.0.238.67]:47078 "EHLO Chamillionaire.breakpoint.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750909AbeC0LuD (ORCPT ); Tue, 27 Mar 2018 07:50:03 -0400 Content-Disposition: inline In-Reply-To: <000000000000f7826f0568630354@google.com> Sender: netdev-owner@vger.kernel.org List-ID: syzbot wrote: [ cc Julian and trimming cc list ] > syzkaller688027/4497 is trying to acquire lock: > (rtnl_mutex){+.+.}, at: [<00000000bb14d7fb>] rtnl_lock+0x17/0x20 > net/core/rtnetlink.c:74 > but task is already holding lock: > IPVS: stopping backup sync thread 4495 ... > (rtnl_mutex){+.+.}, at: [<00000000bb14d7fb>] rtnl_lock+0x17/0x20 > net/core/rtnetlink.c:74 > > other info that might help us debug this: > Possible unsafe locking scenario: > > CPU0 > ---- > lock(rtnl_mutex); > lock(rtnl_mutex); > > *** DEADLOCK *** > > May be due to missing lock nesting notation Looks like this is real, commit e0b26cc997d57305b4097711e12e13992580ae34 ("ipvs: call rtnl_lock early") added rtnl_lock when starting sync thread but socket close invokes rtnl_lock too: > stack backtrace: > rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 > ip_mc_drop_socket+0x88/0x230 net/ipv4/igmp.c:2643 > inet_release+0x4e/0x1c0 net/ipv4/af_inet.c:413 > sock_release+0x8d/0x1e0 net/socket.c:595 > start_sync_thread+0x2213/0x2b70 net/netfilter/ipvs/ip_vs_sync.c:1924 > do_ip_vs_set_ctl+0x1139/0x1cc0 net/netfilter/ipvs/ip_vs_ctl.c:2389