Re: PROBLEM: Memory leak (at least with SLUB) from "secpath_dup" (xfrm) in 3.5+ kernels

On Sun, 21 Oct 2012 23:47:33 +0200
Eric Dumazet [off-list ref] wrote:

OK, so  some layer seems to have a bug if the skb->head is exactly
allocated, instead of having extra tailroom (because of kmalloc-powerof2
alignment)

Or some layer overwrites past skb->cb[] array

If you try to move sp field in sk_buff, does it change something ?

...

Also try to increase tailroom in __netdev_alloc_skb()

Applied both patches, but unfortunately, the problem seem to be still
there.

This time the leaking objects seem to show up as kmalloc-64.

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
266760 265333  99%    0.30K  10260       26     82080K kmemleak_object
157440 157440 100%    0.06K   2460       64      9840K kmalloc-64
 94458  94458 100%    0.10K   2422       39      9688K buffer_head
 27573  27573 100%    0.19K   1313       21      5252K dentry


kmemleak traces:

unreferenced object 0xffff88002f38ec80 (size 64):
  comm "softirq", pid 0, jiffies 4294900815 (age 142.346s)
  hex dump (first 32 bytes):
    01 00 00 00 01 00 00 00 00 08 03 2e 00 88 ff ff  ................
    2b 6f a0 ca 28 b2 4a f1 0a 74 33 74 5a 76 18 cb  +o..(.J..t3tZv..
  backtrace:
    [<ffffffff814da4e3>] kmemleak_alloc+0x21/0x3e
    [<ffffffff810dc1f7>] kmem_cache_alloc+0xa5/0xb1
    [<ffffffff81487bf5>] secpath_dup+0x1b/0x5a
    [<ffffffff81487df9>] xfrm_input+0x64/0x484
    [<ffffffff8147eec3>] xfrm4_rcv_encap+0x17/0x19
    [<ffffffff8147eee4>] xfrm4_rcv+0x1f/0x21
    [<ffffffff8143b4e4>] ip_local_deliver_finish+0x170/0x22a
    [<ffffffff8143b6d6>] ip_local_deliver+0x46/0x78
    [<ffffffff8143b35d>] ip_rcv_finish+0x295/0x2ac
    [<ffffffff8143b936>] ip_rcv+0x22e/0x288
    [<ffffffff8140a65d>] __netif_receive_skb+0x5ba/0x65a
    [<ffffffff8140a898>] netif_receive_skb+0x47/0x78
    [<ffffffff8140b4c3>] napi_skb_finish+0x21/0x54
    [<ffffffff8140b5f3>] napi_gro_receive+0xfd/0x10a
    [<ffffffff81372b47>] rtl8169_poll+0x326/0x4fc
    [<ffffffff8140ad48>] net_rx_action+0x9f/0x188

unreferenced object 0xffff880029b47580 (size 64):
  comm "softirq", pid 0, jiffies 4294926900 (age 143.946s)
  hex dump (first 32 bytes):
    01 00 00 00 01 00 00 00 00 88 07 2e 00 88 ff ff  ................
    00 00 00 00 2f 6f 72 67 2f 66 72 65 65 64 65 73  ..../org/freedes
  backtrace:
    [<ffffffff814da4e3>] kmemleak_alloc+0x21/0x3e
    [<ffffffff810dc1f7>] kmem_cache_alloc+0xa5/0xb1
    [<ffffffff81487bf5>] secpath_dup+0x1b/0x5a
    [<ffffffff81487df9>] xfrm_input+0x64/0x484
    [<ffffffff814bbd74>] xfrm6_rcv_spi+0x19/0x1b
    [<ffffffff814bbd96>] xfrm6_rcv+0x20/0x22
    [<ffffffff814960c7>] ip6_input_finish+0x203/0x31b
    [<ffffffff81496546>] ip6_input+0x1e/0x50
    [<ffffffff81496244>] ip6_rcv_finish+0x65/0x69
    [<ffffffff814964c7>] ipv6_rcv+0x27f/0x2e0
    [<ffffffff8140a65d>] __netif_receive_skb+0x5ba/0x65a
    [<ffffffff8140a898>] netif_receive_skb+0x47/0x78
    [<ffffffff8140b4c3>] napi_skb_finish+0x21/0x54
    [<ffffffff8140b5f3>] napi_gro_receive+0xfd/0x10a
    [<ffffffff81372b47>] rtl8169_poll+0x326/0x4fc
    [<ffffffff8140ad48>] net_rx_action+0x9f/0x188

I've grepped for "/org/free" specifically and sure enough, same scraps
of data seem to be in some of the (varied) dumps there.


-- 
Mike Kazantsev // fraggod.net