lkml.org 
[lkml]   [2006]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 00/10] Kernel memory leak detector 0.8
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
-
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/

\
 
 \ /
  Last update: 2006-07-11 17:47    [W:0.086 / U:1.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site