Re: [PATCH 00/10] Kernel memory leak detector 0.8

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

On 11/07/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> It is DEBUG_MEMLEAK_ORPHAN_FREEING issue. Disabling it solved the
> problem.

OK, thanks for trying.

> orphan pointer 0xc6113bec (size 28):
>   c017392a: <__kmalloc_track_caller>
>   c01631b1: <__kzalloc>
>   c010b7d7: <legacy_init_iomem_resources>
>   c010b89c: <request_standard_resources>
>   c0100b8b: <do_initcalls>
>   c0100c3d: <do_basic_setup>
>   c0100cdb: <init>

That's a real leak. I posted a patch last night that solves this issue
- http://lkml.org/lkml/2006/7/10/370

> This is most common
> orphan pointer 0xf5a6fd60 (size 39):
>   c0173822: <__kmalloc>
>   c01df500: <context_struct_to_string>
>   c01df679: <security_sid_to_context>
>   c01d7eee: <selinux_socket_getpeersec_dgram>
>   f884f019: <unix_get_peersec_dgram>
>   f8850698: <unix_dgram_sendmsg>
>   c02a88c2: <sock_sendmsg>
>   c02a9c7a: <sys_sendto>

Looking at the call trace, the pointer to the memory allocated in
context_struct_to_string() is stored in the "cb" variable in struct
sk_buff (argument passed to selinux_socket_getpeersec_dgram from
unix_get_peersec_dgram).

This pointer should be found when scanning the "struct sk_buff"
blocks, unless you also get a comparable number of "struct sk_buff"
reports (from __alloc_skb). If not, it might be a real leak.

-- 
Catalin