[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180327115001.GC26275@breakpoint.cc>
Date: Tue, 27 Mar 2018 13:50:01 +0200
From: Florian Westphal <fw@...len.de>
To: syzbot <syzbot+a46d6abf9d56b1365a72@...kaller.appspotmail.com>
Cc: netdev@...r.kernel.org, syzkaller-bugs@...glegroups.com, ja@....bg
Subject: Re: possible deadlock in rtnl_lock (5)
syzbot <syzbot+a46d6abf9d56b1365a72@...kaller.appspotmail.com> 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
Powered by blists - more mailing lists