ipv4: fix a potential deadlock in mcast getsockopt() path
authorWANG Cong <xiyou.wangcong@gmail.com>
Tue, 3 Nov 2015 23:41:16 +0000 (15:41 -0800)
committerDavid S. Miller <davem@davemloft.net>
Thu, 5 Nov 2015 02:29:59 +0000 (21:29 -0500)
commit87e9f0315952b0dd8b5e51ba04beda03efc009d9
tree0e7621915ad9824230e0a33d1027f6c7d8e35e36
parent4ee3bd4a8c7463cdef0b82ebc33fc94a9170a7e0
ipv4: fix a potential deadlock in mcast getsockopt() path

Sasha reported the following lockdep warning:

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(sk_lock-AF_INET);
                                lock(rtnl_mutex);
                                lock(sk_lock-AF_INET);
   lock(rtnl_mutex);

This is due to that for IP_MSFILTER and MCAST_MSFILTER, we take
rtnl lock before the socket lock in setsockopt() path, but take
the socket lock before rtnl lock in getsockopt() path. All the
rest optnames are setsockopt()-only.

Fix this by aligning the getsockopt() path with the setsockopt()
path, so that all mcast socket path would be locked in the same
order.

Note, IPv6 part is different where rtnl lock is not held.

Fixes: 54ff9ef36bdf ("ipv4, ipv6: kill ip_mc_{join, leave}_group and ipv6_sock_mc_{join, drop}")
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/ipv4/igmp.c
net/ipv4/ip_sockglue.c