NET_NS: unregister_netdevice: waiting for lo to become free (adding ipv6 address to interface)
in [Kernel]
|
Prev: [PATCH 3/12] scsi: megaraid_sas - Online Controller Reset - III: add the reset function for Gen2 related chip
Next: [PATCH 7/42] net/atm: Adjust confusing if indentation
From: Eric W. Biederman on 5 Aug 2010 16:00 Michael Leun <lkml20100708(a)newton.leun.net> writes: > On Thu, 05 Aug 2010 02:51:29 -0700 > ebiederm(a)xmission.com (Eric W. Biederman) wrote: > >> >> > Jul 10 20:02:36 doris kernel: unregister_netdevice: waiting for >> >> > lo to become free. Usage count = 3 [repeated] >> >> >> >> How many times? >> > >> > Unfortunately looks like indefinitely. Never watched longer so far >> > (rebooted soon), but I'm seeing this message now repeated every 10 >> > secs for ~10 minutes on a idle system. >> >> Ugh. A real bug then. These can be a pain to track down and fix. I >> think the last one of these I tracked down took a couple of weeks. I >> will start digging in when I get back from vacation. > > OK, fortunately (hopefully) you have not put to much time onto that so > far - because everything I told about usage of tun and difference > between ssh and openvpn is complete nonsense. > > I happen to have an script in that openvpn config, which puts an ipv6 > address on the vpn device. > > Putting an ipv6 address on a device seems to be the trigger: > > OrigNS > # ip link add type veth > OrigNS > # ip link set dev veth0 up > OrigNS > # unshare -n /bin/bash > NewNS > # echo $$ > <SomePID> > OrigNS > # ip link set dev veth1 netns <SomePID> # this, of course is on a different terminal > NewNS > # ip link set dev veth1 up > NewNS > # ip -6 addr add dev veth1 fd50:dead:beef::1/64 > NewNS > # exit > > Yields > > kernel: unregister_netdevice: waiting for veth1 to become free. Usage count = 3 > > Oh - its veth1 this time, not lo - add an "ip link set up dev lo" in the above scenario just after the unshare, and you get the message with lo. > > One might ask, if > >> # unshare -n /bin/bash >> # ip link set up dev lo >> # ip -6 addr add dev veth1 fd50:dead:beef::1/64 >> # exit > > also does the trick, so I tried it - and it does NOT. > > In the above scenario, not setting veth0 and veth1 up also makes it not happen. Only setting veth1 up also is not enough (seems to need to be "really up" what as you shurely know with veth is only the case when both sides are up). > > I hope, this makes it somewhat easier to track that down. What puzzles me is that on a slightly patched 2.6.32 (so sysfs works) and I am doing very similar things (openvpn tunnels, ipv6 to the network as a whole etc), and I am not seeing the infinite unregister_netdevice: messages you are talking about. When a network device is removed most references to it are redirected to the loopback device so a normal network device should not see the worst of the problems. That is why lo showed up. In that context I'm a bit surprised you managed trigger a problem on veth1. I wonder what has changed with ipv6 recently. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |