Hi, Pablo, В Пн, 28/04/2014 в 16:23 +0200, Pablo Neira Ayuso пишет: > Hi, > > On Mon, Apr 07, 2014 at 03:58:49PM +0400, Kirill Tkhai wrote: > > Clusterip target does dev_hold() in .checkentry, while dev_put() in .destroy. > > So, unregister_netdevice catches the leak: > > > > # modprobe dummy > > # iptables -A INPUT -d 10.31.3.236 -j CLUSTERIP --new --hashmode sourceip -i dummy0 --clustermac 01:aa:7b:47:f7:d7 --total-nodes 2 --local-node 1 > > # rmmod dummy > > > > Message from syslogd@localhost ... > > kernel: unregister_netdevice: waiting for dummy0 to become free. Usage count = 1 > > > [...] > > 1 file changed, 134 insertions(+), 12 deletions(-) > > I have spinned several times on this patch, and I'm not very happy > with taking this fix: > > 1) It's quite large fix for a situation that seems unlikely to me. We have several reports from containers users, who bumped into this. The hang happens on netns stop, it's 100% reproducible. Every time a container is stopping or a device is going away, the unregistration fails and hungs if CLUSTERIP is used. So, we'd want to have some fix of this. > 2) We have this problem since the beginning, since the CLUSTERIP > target was merged mainstream. Some time ago we discovered, several our BUGs are connected with this problem. It's not once-only for us. > 3) We have theses days the cluster match, which is more flexible as > you can also use it not only for backend, but also in active-active > gateway setups. It just requires a couple of arptables rules for > mangling ARP replies to include the multicast MAC there. Yes, but CLUSTERIP is still in upstream, and some people still use it. This bug potentially is a bomb, when the only user of a container can kill all the system. > Perhaps linking net_device structure with the module that have created > would simplify this, but I guess David won't take such patch just to > fix this rare iptables extension, unless this is manifesting in other > netdev code, eg. tunneling protocols. Is there a better decidion? We'd could fix it in other way if you suggest. Thanks, Kirill -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
