As it is when loopback_dev loses all of its IPv4 addresses its corresponding idev will be destroyed. Unfortunately as of last August route.c relies on the loopback idev to kill references to other i
The same problem exists for IPv6. Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxx
Both patches applied to the 2.6.12-pending tree. I wish ->notifier_call()'s value was actually checked, we could do intelligent things instead of panic()'ing when (for example) loopback's idev alloca
Yes I missed the ipv6 module case. It would be very nice to be able to return errors there. Since we initiate the loopback registration from addrconf_init, perhaps we can get away for the time being
Hi: As it is when loopback_dev loses all of its IPv4 addresses its corresponding idev will be destroyed. Unfortunately as of last August route.c relies on the loopback idev to kill references to othe
The same problem exists for IPv6. Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxx
Both patches applied to the 2.6.12-pending tree. I wish ->notifier_call()'s value was actually checked, we could do intelligent things instead of panic()'ing when (for example) loopback's idev alloca
Yes I missed the ipv6 module case. It would be very nice to be able to return errors there. Since we initiate the loopback registration from addrconf_init, perhaps we can get away for the time being