On Wed, 2016-10-19 at 11:20 -0700, Cong Wang wrote:
> Baozeng reported this deadlock case:
>
> CPU0 CPU1
> ---- ----
> lock([ 165.136033] sk_lock-AF_INET6);
> lock([ 165.136033] rtnl_mutex);
> lock([ 165.136033] sk_lock-AF_INET6);
> lock([ 165.136033] rtnl_mutex);
>
> Similar to commit 87e9f0315952
> ("ipv4: fix a potential deadlock in mcast getsockopt() path")
> this is due to we still have a case, ipv6_sock_mc_close(),
> where we acquire sk_lock before rtnl_lock. Close this deadlock
> with the similar solution, that is always acquire rtnl lock first.
>
> Fixes: baf606d9c9b1 ("ipv4,ipv6: grab rtnl before locking the socket")
> Reported-by: Baozeng Ding <splovi...@gmail.com>
> Tested-by: Baozeng Ding <splovi...@gmail.com>
> Cc: Marcelo Ricardo Leitner <marcelo.leit...@gmail.com>
> Signed-off-by: Cong Wang <xiyou.wangc...@gmail.com>
> ---
> net/ipv6/af_inet6.c | 2 ++
> net/ipv6/ipv6_sockglue.c | 1 +
> net/ipv6/mcast.c | 4 ++--
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
> index 46ad699..b8c8d20 100644
> --- a/net/ipv6/af_inet6.c
> +++ b/net/ipv6/af_inet6.c
> @@ -414,7 +414,9 @@ int inet6_release(struct socket *sock)
> return -EINVAL;
>
> /* Free mc lists */
> + rtnl_lock();
Certainly not.
Some people want IPv6 being reasonably fast.
> ipv6_sock_mc_close(sk);
> + rtnl_unlock();
>
