lkml.org 
[lkml]   [2006]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Possible kernel memory leaks
    From
    Date
    Catalin Marinas <catalin.marinas@gmail.com> wrote:
    > There are some possible kernel memory leaks discovered by kmemleak. I
    > didn't have time for investigating them. Please let me know if they are
    > not leaks so that I can improve kmemleak (or just add a false alarm call):
    [...]
    > - acpi_ev_execute_reg_method in drivers/acpi/events/evregion.c - I'm not
    > sure about this but kmemleak reports an orphan pointer on the following
    > allocation path:
    > c0159372: <kmem_cache_alloc>
    > c01ffa07: <acpi_os_acquire_object>
    > c0215b3a: <acpi_ut_allocate_object_desc_dbg>
    > c02159ce: <acpi_ut_create_internal_object_dbg>
    > c0203784: <acpi_ev_execute_reg_method>
    > c0203db4: <acpi_ev_reg_run>
    > c020ed17: <acpi_ns_walk_namespace>
    > c0203d6b: <acpi_ev_execute_reg_methods>
    > Is acpi_ut_remove_reference actually removing the params[0/1]?

    After a quick check, the reference counts after the
    acpi_ns_evaluate_by_handle() call in acpi_ev_execute_reg_method look
    like this (they were both 1 before this call):

    params[0]->common.reference_count = 1
    params[1]->common.reference_count = 2

    and therefore acpi_ut_remove_reference() doesn't free
    params[1]. Kmemleak, however, cannot find the params[1] value while
    scanning the memory and therefore reports it as a leak.

    Is this normal behaviour for the acpi_ev_execute_reg_method function?
    There isn't anything obvious looking at the calling tree (which I
    would say is pretty complex).

    --
    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-05-31 15:50    [W:8.007 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site