igmp: fix the problem when mc leave group
Subsystems (3)
PATCH v2 1/1 igmp: fix the problem when mc leave group
The problem was triggered by these steps:
1) create socket, bind and then setsockopt for add mc group. mreq.imr_multiaddr.s_addr = inet_addr("255.0.0.37"); mreq.imr_interface.s_addr = inet_addr("192.168.1.2"); setsockopt(sockfd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));
2) drop the mc group for this socket.
mreq.imr_multiaddr.s_addr = inet_addr("255.0.0.37"); mreq.imr_interface.s_addr = inet_addr("0.0.0.0"); setsockopt(sockfd, IPPROTO_IP, IP_DROP_MEMBERSHIP, &mreq, sizeof(mreq));
3) and then drop the socket, I found the mc group was still used by the dev:
netstat -g
Interface RefCnt Group
--------------- ------ ---------------------
eth2 1 255.0.0.37
Normally even though the IP_DROP_MEMBERSHIP return error, the mc group still need to be released for the netdev when drop the socket, but this process was broken when route default is NULL, the reason is that:
The ip_mc_leave_group() will choose the in_dev by the imr_interface.s_addr, if input addr is NULL, the default route dev will be chosen, then the ifindex is got from the dev, then polling the inet->mc_list and return -ENODEV, but if the default route dev is NULL, the in_dev and ifIndex is both NULL, when polling the inet->mc_list, the mc group will be released from the mc_list, but the dev didn't dec the refcnt for this mc group, so when dropping the socket, the mc_list is NULL and the dev still keep this group.
v1->v2: According Hideaki's suggestion, we should align with IPv6 (RFC3493) and BSDs,
so I add the checking for the in_dev before polling the mc_list, make sure when we remove the mc group, dec the refcnt to the real dev which was using the mc address. The problem would never happened again.
--- net/ipv4/igmp.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
net/ipv4/igmp.c +6 -4
@@ -1944,6 +1944,10 @@ int ip_mc_leave_group(struct sock *sk, struct ip_mreqn *imr)rtnl_lock (); in_dev =ip_mc_find_dev (net, imr); +if (!in_dev) { + ret = -ENODEV ; + goto out; + } ifindex = imr->imr_ifindex; for (imlp = &inet->mc_list; (iml = rtnl_dereference(*imlp)) != NULL;
@@ -1961,16 +1965,14 @@ int ip_mc_leave_group(struct sock *sk, struct ip_mreqn *imr) *imlp = iml->next_rcu; -if (in_dev) -ip_mc_dec_group (in_dev, group); +ip_mc_dec_group (in_dev, group);rtnl_unlock ();/* decrease mem now to avoid the memleak warning */ atomic_sub (sizeof (*iml), &sk->sk_omem_alloc);kfree_rcu (iml, rcu);return 0 ; } -if (!in_dev) - ret = -ENODEV ; +out:rtnl_unlock ();return ret; }
Signature · 1 line
1.7.12
From: Ding Tianhong <[email protected]>
Date: Wed, 2 Jul 2014 13:50:48 +0800
Quoted 31 lines
The problem was triggered by these steps:
1) create socket, bind and then setsockopt for add mc group.
mreq.imr_multiaddr.s_addr = inet_addr("255.0.0.37"); mreq.imr_interface.s_addr = inet_addr("192.168.1.2"); setsockopt(sockfd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));2) drop the mc group for this socket.
mreq.imr_multiaddr.s_addr = inet_addr("255.0.0.37"); mreq.imr_interface.s_addr = inet_addr("0.0.0.0"); setsockopt(sockfd, IPPROTO_IP, IP_DROP_MEMBERSHIP, &mreq, sizeof(mreq));3) and then drop the socket, I found the mc group was still used by the dev:
netstat -g Interface RefCnt Group --------------- ------ --------------------- eth2 1 255.0.0.37Normally even though the
IP_DROP_MEMBERSHIPreturn error, the mc group still need to be released for the netdev when drop the socket, but this process was broken when route default is NULL, the reason is that:The
ip_mc_leave_group()will choose thein_devby the imr_interface.s_addr, if input addr is NULL, the default route dev will be chosen, then the ifindex is got from the dev, then polling theinet->mc_listand return-ENODEV, but if the default route dev is NULL, thein_devand ifIndex is both NULL, when polling theinet->mc_list, the mc group will be released from themc_list, but the dev didn't dec the refcnt for this mc group, so when dropping the socket, themc_listis NULL and the dev still keep this group.
Quoted 6 lines
v1->v2: According Hideaki's suggestion, we should align with IPv6 (RFC3493) and BSDs,
so I add the checking for thein_devbefore polling themc_list, make sure when we remove the mc group, dec the refcnt to the real dev which was using the mc address. The problem would never happened again.Signed-off-by Ding Tianhong <[email protected]>
Applied, thank you.
Quoted 34 lines · David Miller
From: Ding Tianhong <[email protected]>
Date: Wed, 2 Jul 2014 13:50:48 +0800Quoted 31 lines
The problem was triggered by these steps:
1) create socket, bind and then setsockopt for add mc group.
mreq.imr_multiaddr.s_addr = inet_addr("255.0.0.37"); mreq.imr_interface.s_addr = inet_addr("192.168.1.2"); setsockopt(sockfd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));2) drop the mc group for this socket.
mreq.imr_multiaddr.s_addr = inet_addr("255.0.0.37"); mreq.imr_interface.s_addr = inet_addr("0.0.0.0"); setsockopt(sockfd, IPPROTO_IP, IP_DROP_MEMBERSHIP, &mreq, sizeof(mreq));3) and then drop the socket, I found the mc group was still used by the dev:
netstat -g Interface RefCnt Group --------------- ------ --------------------- eth2 1 255.0.0.37Normally even though the
IP_DROP_MEMBERSHIPreturn error, the mc group still need to be released for the netdev when drop the socket, but this process was broken when route default is NULL, the reason is that:The
ip_mc_leave_group()will choose thein_devby the imr_interface.s_addr, if input addr is NULL, the default route dev will be chosen, then the ifindex is got from the dev, then polling theinet->mc_listand return-ENODEV, but if the default route dev is NULL, thein_devand ifIndex is both NULL, when polling theinet->mc_list, the mc group will be released from themc_list, but the dev didn't dec the refcnt for this mc group, so when dropping the socket, themc_listis NULL and the dev still keep this group.
Quoted 9 lines
Quoted 6 lines
v1->v2: According Hideaki's suggestion, we should align with IPv6 (RFC3493) and BSDs,
so I add the checking for thein_devbefore polling themc_list, make sure when we remove the mc group, dec the refcnt to the real dev which was using the mc address. The problem would never happened again.Signed-off-by Ding Tianhong <[email protected]>Applied, thank you.
Hi david:
Can you queue this patch to stable, this problem is existed in every earlier kernel version, and could be triggered easily, I think we should fix it for every stable tree.
Ding
Quoted 2 lines
.
David Miller
maintainerFrom: Ding Tianhong <[email protected]>
Date: Tue, 8 Jul 2014 12:47:16 +0800
Quoted 3 lines
Can you queue this patch to stable, this problem is existed in every earlier kernel version, and could be triggered easily, I think we should fix it for every stable tree.
Done.