From: Ben Greear <[EMAIL PROTECTED]> Date: Sun, 28 Aug 2005 22:57:38 -0700
> In the meantime, is there any debugging code relating to neighbor > objects that I can use to help debug this? Neighbour table entries are held by routing cache entries. Adding a leak detection layer for neighbour table entries probably isn't that useful as a result. More useful would be a route leak detection layer. Actually, the leaks here are different to discover than the usual kind like the net devices. When a device is unloaded or brought down, we try to drop all the device et al. references in the destination cache entries on the garbage collection list. This is done by net/core/dst.c/dst_ifdown(). Really, I think you've found a route leak. Alexey Kuznetsov made a posting today describing the lifetimes of destination cache entries (and as a consequence routing cache entries), describing also what lists and tables they live in in various stages and what to look for in routing cache dumps in order to detect leaks of some types. You should really read up on that. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
