On Sun, 21 Oct 2012 23:47:33 +0200
Eric Dumazet <eric.dumazet@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature