On Mon, Sep 10, 2001 at 02:30:47PM +0200, Thomas Brunner wrote:
> Hello!
>
> > After two days of battle, rebooting my box countless times, I
> > managed to fix a memory leak in the IrDA stack (and understand why my
> > first fix was crashing).
>
> I was also looking at it, the sk->destruct seemed to be the problem, right?
Correct. Le patch est documente ;-)
> > Now, I don't say that I've fixed *all* memory leaks in the
> > IrDA stack. In particular, I suspect we loose some skbuffs there and
> > there, but I have no hard evidences.
>
> well, the sock leak is definitely gone,
Good.
> but there is unfortunately still a
> sk_buff leak. When I run my test program, which just opens a socket,
> transmits 1.5k and closes the socket over and over again, the
> skbuff_head_cache and size-64 count in /proc/slabinfo increase by more or
> less one for every socket used.
That's not too bad. A socket leak mean at least 1K wasted, in
this case we loose only ~200k.
> At first I thought this problem and the sock
> leak are related but now I'm not sure anymore, since the sock leak is fixed
> and the skbuff leak is still here.
Notice that the patch flush the socket receive queue, which
would have fixed such problem (the other socket queues are not used).
> I will try to find it but it's not very easy, if somebody has an idea, where
> the problem could be, I'd happy to hear it. Also it would be interesting to
> know if other people observe the same problem.
Yes, it's not easy at all. For me, my box is connected to the
network, so it's hard to track done precisely that
My guess is that the normal data path is ok (i.e. all the
higher layer packet we Tx or Rx), and the leak is one of the
management packet (discovery, LAP connection, IAP query, TTP
connection, TTP disconnection, LAP disconnection and the like). This
is consistent with the 64 byte size of the leak.
There is many function in the IrDA stack that are the terminal
point of management packets, and you need to check all of them to make
sure that they free their packet. Then, there is also many place that
just discard packets because the handler is not active.
The third kind is some packet that the stack store
temporarily. Those one a pain in the butt to check, because there is
many exit point. My number one suspect is (lsap_cb *)->conn_skb, I'm
willing to bet that there is some case where it doesn't get freed (I
remember beeing puzzled by some code). But if you look closely in the
IrDA header files, you will find many of these...
> cheers!
> -thomas-
Have fun...
Jean
_______________________________________________
Linux-IrDA mailing list - [EMAIL PROTECTED]
http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda
