David S. Miller wrote:
You can, BTW, log the value of "__builtin_return_address(0)" at the time of the neighbour table entry creation, so see who asked for it. That might help track it down.
Yep, that was helpful. The caller is arp_bind_neighbour. With regard to re-writing the ref-counting logic to be more like what you suggested, I don't think I'll be able to do it. I tried to do something similar with the neighbour class on friday, and got nowhere fast. The ability to pass in generic keys greatly simplifies much of the code because we often do a get_foo before we know exactly where we are going to store it. With generics, I can acquire the generic key untill we know the official key, then acquire the official key and drop the generic. If the main concern is the malloc, I will modify the code to allow the caller to pass in the struct to hold the pointers. That way, someone could convert existing code or write new code using logic similar to what you suggested, while retaining the coverage I have already implemented for use on the stack and other places it is difficult to use passed-in-structs. If that will allow the ref-counting debugging to go in, I'll make the needed changes and post a patch. Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - 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
