[lkml]   [2006]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 00/10] Kernel memory leak detector 0.8
On 11/07/06, Michal Piotrowski <> 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

> 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

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-07-11 17:47    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean