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 l
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.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo
David S. Miller wrote:
From: Ben Greear <[EMAIL PROTECTED]>
Date: Fri, 02 Sep 2005 13:53:58 -0700
I'm trying to write some code to walk all of the places where
routes might exist and find any that reference a particular
net-device.
Man, good luck. The IPSEC destination cache entries live i
David S. Miller wrote:
It is better to implement this via backpointers in the
debugging information, perhaps.
This appears to be the neighbour struct that holds the leaked
reference:
Sep 2 16:11:27 sb65g2 kernel: Leaked neighbor structure:
Sep 2 16:11:27 sb65g2 kernel: next: tbl
David S. Miller wrote:
From: Ben Greear <[EMAIL PROTECTED]>
Date: Fri, 02 Sep 2005 13:53:58 -0700
I'm trying to write some code to walk all of the places where
routes might exist and find any that reference a particular
net-device.
Man, good luck. The IPSEC destination cache entries live i
From: Ben Greear <[EMAIL PROTECTED]>
Date: Fri, 02 Sep 2005 13:53:58 -0700
> I'm trying to write some code to walk all of the places where
> routes might exist and find any that reference a particular
> net-device.
Man, good luck. The IPSEC destination cache entries live in
chains only obtainabl
