Re: [PATCH 2.6.19-rc1 00/10] Kernel memory leak detector 0.11

["Catalin Marinas" <catalin.marinas@gmail.com>]

Hi Michal,

On 09/10/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> I have a new false positives :)
> http://www.stardust.webpages.pl/files/o_bugs/kmemleak-0.11/ml.txt

I eventually found some time to look at these reports. See below for
comments (I removed the duplicates):

unreferenced object 0xdff2213c (size 398):
 [<c0166bc1>] memleak_alloc
 [<c0164d15>] __kmalloc_track_caller
 [<c01548c1>] __kzalloc
 [<c024361b>] platform_device_alloc
 [<c03e9076>] add_pcspkr
 [<c03e48bd>] do_initcalls
 [<c03e496a>] do_basic_setup
 [<c0100421>] init
 [<c01039ab>] kernel_thread_helper
 [<ffffffff>]

Kmemleak is probably right in that this code will never be able to
free the platform device (the pointer was only stored on the stack).
However, this won't be needed and I'll mark it as not being a leak.

unreferenced object 0xf4f4eb68 (size 8):
 [<c0166bc1>] memleak_alloc
 [<c0164d15>] __kmalloc_track_caller
 [<c01548c1>] __kzalloc
 [<c0166479>] __percpu_alloc_mask
 [<fd954a1b>] snmp6_mib_init
 [<fd926017>] ip6t_hook
 [<fd9260f2>] __param_forward
 [<c013b5ad>] sys_init_module
 [<c0102dd5>] sysenter_past_esp
 [<ffffffff>]

This might be a real leak since the previous kmemleak versions were
ignoring all the percpu allocations. I'm a bit confused about the
calling chain between ip6t_hook and snmp6_mib_init. Maybe the network
people could shed some light on this.

unreferenced object 0xf4a17304 (size 1412):
 [<c0166bc1>] memleak_alloc
 [<c0164c2d>] __kmalloc
 [<fd95c587>] addrconf_sysctl_register
 [<fd926337>] __param_forward
 [<fd92619e>] __param_forward
 [<c013b5ad>] sys_init_module
 [<c0102dd5>] sysenter_past_esp
 [<ffffffff>]
unreferenced object 0xf48f75bc (size 8):
 [<c0166bc1>] memleak_alloc
 [<c0164d15>] __kmalloc_track_caller
 [<c0154915>] kstrdup
 [<fd95c5fa>] addrconf_sysctl_register
 [<fd926337>] __param_forward
 [<fd92619e>] __param_forward
 [<c013b5ad>] sys_init_module
 [<c0102dd5>] sysenter_past_esp
 [<ffffffff>]

I have the same problem with the stack trace here - can't find
__param_forward in the code and it also looks strange to have a
recursive call into this function.

I suspect you use the skge.c Ethernet driver. Is it possible to link
this into the kernel (not as a module) and maybe together with the
networking stuff? It might show a clearer stack trace.

unreferenced object 0xf44869e4 (size 160):
 [<c0166bc1>] memleak_alloc
 [<c0164a30>] kmem_cache_alloc
 [<c02a91a0>] __alloc_skb
 [<f9882439>] FillRxDescriptor
 [<f9882408>] FillRxRing
 [<f9881bdf>] SkGeOpen
 [<c02adcda>] dev_open
 [<c02af332>] dev_change_flags
 [<c02e27dd>] devinet_ioctl
 [<c02e4372>] inet_ioctl
 [<c02a5844>] sock_ioctl
 [<ffffffff>]
unreferenced object 0xf45101ec (size 1828):
 [<c0166bc1>] memleak_alloc
 [<c0164d15>] __kmalloc_track_caller
 [<c02a91cb>] __alloc_skb
 [<f9882439>] FillRxDescriptor
 [<f9882408>] FillRxRing
 [<f9881bdf>] SkGeOpen
 [<c02adcda>] dev_open
 [<c02af332>] dev_change_flags
 [<c02e27dd>] devinet_ioctl
 [<c02e4372>] inet_ioctl
 [<c02a5844>] sock_ioctl
 [<ffffffff>]

The above is probably not a leak but it looks more like badly written
code. It looks like the pointers to the sk_buff structures are stored
in memory allocated by pci_alloc_consistent. Kmemleak doesn't scan
this area as it is usually meant for DMA'ing data and not for holding
pointers kernel structures. I can mark it as not a leak.

Thanks.

--
Catalin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/