[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKedQg_qWUgXzsTrQJ0NGoxzKHaQvAnZ2pztzAXVHbq9H4gLRQ@mail.gmail.com>
Date: Fri, 13 Jan 2012 17:29:59 -0700
From: Bruce Jones <brucerjones@...il.com>
To: netdev@...r.kernel.org
Subject: neighbour table overflow errors. leaking neighbours I think
I am seeing neighbour table overflow messages so I began exploring
neighbour structure reference counts to try and understand the issue
and see why they are not being reclaimed by the garbage collector.
I'm pretty new to the kernel so have just been sprinkling printks
around to try to understand how this all works.
The box is running 2.6.32.50. I know that is old, but the current
code for 3.2.1 looks like it is doing basically the same thing.
I am running a test that is blasting the box with lots of bogus tcp
packets. This results in calls to tcp_v4_send_reset(). That then
calls ip_send_reply() which calls ip_route_output_key() which causes a
new neighbour entry to be allocated. Then back in ip_send_reply(),
ip_append_data() is called. I find that this call is failing and
returning ENOBUFS. The return value from ip_append_data() is not
checked in ip_send_reply() so nothing is cleaned up. I see that other
calls to ip_append_data() do check the return value and call some
cleanup function. Those cleanup functions do things like release skb,
dsts, etc. I image I might be leaking those things too, though I have
only looked at nieghbours. My question is should there be a similar
function to clean up if ip_append_data fails() in ip_send_reply() or
is there a reason that that particular call doesn't check for errors
when the others do?
Thanks,
Bruce
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists