[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    [W:0.032 / U:9.416 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site