Sock leak in net/ipv4/af_inet.c - 2.4.26

Sock leak in net/ipv4/af_inet.c - 2.4.26

[Dickey, Dan]

Alexey & Dave,
I hope these are good addresses for you - it has been a few years since
I've tried to contact you.

I've found a leak in af_inet.c, routine inet_create().
It allocates from the sock slab using sk_alloc(), but
sk_free() is never called on these sock structs.
I'm not that familiar with the af_inet code, but I'll
continue taking a look at it to try and determine where
the missing sk_free() is supposed to be.
If either of you or anyone else has an idea, please
let me know.  We have several 2GB mem systems that need
to be rebooted every few days because of this problem.

Oh - by the way, it looks like this is happening in
net/ipv4/tcp_minisocks.c as well.  Routine tcp_create_openreq_child().
There is no corresponding sk_free() call for the sk_alloc() in here.

In order to track these down, I've added some simple debug code
around the sk_alloc/sk_free calls to track allocations.  I know
where the leaky sock structs are being allocated from, but not
where they should be freed.

The bugzilla.kernel.org bug # is 2676.
	-Dan

------
Dan A. Dickey
dan.dickey@savvis.net

Re: Sock leak in net/ipv4/af_inet.c - 2.4.26

[Marc-Christian Petersen]

On Tuesday 11 May 2004 18:24, Dickey, Dan wrote:

Hi Dan,

> I've found a leak in af_inet.c, routine inet_create().
> It allocates from the sock slab using sk_alloc(), but
> sk_free() is never called on these sock structs.
> I'm not that familiar with the af_inet code, but I'll
> continue taking a look at it to try and determine where
> the missing sk_free() is supposed to be.
> If either of you or anyone else has an idea, please
> let me know.  We have several 2GB mem systems that need
> to be rebooted every few days because of this problem.
> Oh - by the way, it looks like this is happening in
> net/ipv4/tcp_minisocks.c as well.  Routine tcp_create_openreq_child().
> There is no corresponding sk_free() call for the sk_alloc() in here.
> In order to track these down, I've added some simple debug code
> around the sk_alloc/sk_free calls to track allocations.  I know
> where the leaky sock structs are being allocated from, but not
> where they should be freed.

am I silly or do I see lots of sk_free(sk); in there?

ciao, Marc

Re: Sock leak in net/ipv4/af_inet.c - 2.4.26

[Dan A. Dickey]

On Tuesday 11 May 2004 11:43, Marc-Christian Petersen wrote:
> On Tuesday 11 May 2004 18:24, Dickey, Dan wrote:
>
> Hi Dan,
>
> > I've found a leak in af_inet.c, routine inet_create().
> > It allocates from the sock slab using sk_alloc(), but
> > sk_free() is never called on these sock structs.
> > I'm not that familiar with the af_inet code, but I'll
> > continue taking a look at it to try and determine where
> > the missing sk_free() is supposed to be.
> > If either of you or anyone else has an idea, please
> > let me know.  We have several 2GB mem systems that need
> > to be rebooted every few days because of this problem.
> > Oh - by the way, it looks like this is happening in
> > net/ipv4/tcp_minisocks.c as well.  Routine tcp_create_openreq_child().
> > There is no corresponding sk_free() call for the sk_alloc() in here.
> > In order to track these down, I've added some simple debug code
> > around the sk_alloc/sk_free calls to track allocations.  I know
> > where the leaky sock structs are being allocated from, but not
> > where they should be freed.
>
> am I silly or do I see lots of sk_free(sk); in there?
>
> ciao, Marc

Marc,
there are zero sk_free() calls in tcp_minisocks.c and
three in af_inet.c.  Go take another look.
Remember - 2.4.26 sources.
	-Dan

-- 
Dan A. Dickey
dan.dickey@savvis.net

Re: Sock leak in net/ipv4/af_inet.c - 2.4.26

[David S. Miller]

The sk_free() should occur when the final sock_put() call brings the count
down to zero, then the socket destroy function is called and the eventual
sk_free() occurs there.

Re: Sock leak in net/ipv4/af_inet.c - 2.4.26

[Dan A. Dickey]

On Tuesday 11 May 2004 13:59, David S. Miller wrote:
> The sk_free() should occur when the final sock_put() call brings the count
> down to zero, then the socket destroy function is called and the eventual
> sk_free() occurs there.

Yes, I'm figuring this out.
I think my earlier report of this problem was a bit premature.
I'm refining my debug code and will let you know what I find.
	-Dan

-- 
Dan A. Dickey
dan.dickey@savvis.net