On Thu, Jan 27, 2005 at 12:33:26PM -0800, David S. Miller wrote:
So they won't be listed in /proc/net/rt_cache (since they've been
removed from the lookup table) but they will be accounted for in
/proc/net/stat/rt_cache until the final release is done on the
routing cache object and it can be completely freed up.
Do you happen to be using IPV6 in any way by chance?
Yes. Someone suggested this evening that there may have been a recent
change to do with some IPv6 refcounting which may have caused this
problem. Is that something you can confirm?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Fri, 28 Jan 2005 00:17:01 +0000
Russell King [off-list ref] wrote:
Yes. Someone suggested this evening that there may have been a recent
change to do with some IPv6 refcounting which may have caused this
problem. Is that something you can confirm?
Yep, it would be this change below. Try backing it out and see
if that makes your leak go away.
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/01/14 20:41:55-08:00 herbert@gondor.apana.org.au
# [IPV6]: Fix locking in ip6_dst_lookup().
#
# The caller does not necessarily have the socket locked
# (udpv6sendmsg() is one such case) so we have to use
# sk_dst_check() instead of __sk_dst_check().
#
# Signed-off-by: Herbert Xu [off-list ref]
# Signed-off-by: David S. Miller [off-list ref]
#
# net/ipv6/ip6_output.c
# 2005/01/14 20:41:34-08:00 herbert@gondor.apana.org.au +3 -3
# [IPV6]: Fix locking in ip6_dst_lookup().
#
# The caller does not necessarily have the socket locked
# (udpv6sendmsg() is one such case) so we have to use
# sk_dst_check() instead of __sk_dst_check().
#
# Signed-off-by: Herbert Xu [off-list ref]
# Signed-off-by: David S. Miller [off-list ref]
#
diff -Nru a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
--- a/net/ipv6/ip6_output.c 2005-01-27 16:07:21 -08:00
+++ b/net/ipv6/ip6_output.c 2005-01-27 16:07:21 -08:00
@@ -745,7 +745,7 @@
if (sk) {
struct ipv6_pinfo *np = inet6_sk(sk);
- *dst = __sk_dst_check(sk, np->dst_cookie);
+ *dst = sk_dst_check(sk, np->dst_cookie);
if (*dst) {
struct rt6_info *rt = (struct rt6_info*)*dst;
@@ -772,9 +772,9 @@
&& (np->daddr_cache == NULL ||
!ipv6_addr_equal(&fl->fl6_dst, np->daddr_cache)))
|| (fl->oif && fl->oif != (*dst)->dev->ifindex)) {
+ dst_release(*dst);
*dst = NULL;
- } else
- dst_hold(*dst);
+ }
}
}
On Fri, Jan 28, 2005 at 12:17:01AM +0000, Russell King wrote:
On Thu, Jan 27, 2005 at 12:33:26PM -0800, David S. Miller wrote:
quoted
So they won't be listed in /proc/net/rt_cache (since they've been
removed from the lookup table) but they will be accounted for in
/proc/net/stat/rt_cache until the final release is done on the
routing cache object and it can be completely freed up.
Do you happen to be using IPV6 in any way by chance?
Yes. Someone suggested this evening that there may have been a recent
change to do with some IPv6 refcounting which may have caused this
problem. Is that something you can confirm?
FWIW, I do not use IPv6, and it is not compiled into the kernel.
Phil