From: Catalin Marinas <catalin.marinas@arm.com>
To: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: Possible kernel memory leaks
Date: Fri, 02 Jun 2006 10:41:37 +0100 [thread overview]
Message-ID: <tnx4pz3x5bi.fsf@arm.com> (raw)
In-Reply-To: <tnxk682wbk8.fsf@arm.com> (Catalin Marinas's message of "Wed, 31 May 2006 14:47:35 +0100")
Catalin Marinas <catalin.marinas@arm.com> wrote:
> Catalin Marinas <catalin.marinas@gmail.com> wrote:
>> There are some possible kernel memory leaks discovered by kmemleak.
> [...]
>> - 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.
I'll keep investigating this as I think its a real object
leak. Looking at why params[1] has a different reference_count from
params[0], led me to the following backtrace on the ref count
increment (that's getting really complicated):
acpi_ut_add_reference
acpi_ds_method_data_get_value
acpi_ex_resolve_object_to_value
acpi_ex_resolve_to_value
acpi_ex_resolve_operands
(I have a suspicion that the above function should call
acpi_ut_remove_reference(obj_desc) on an error return path but it
actually doesn't and, therefore, the ref count remains
incremented. In this function, params[0] ref count is 3 but the
one for params[1] becomes 4)
acpi_ds_exec_end_op (called via walk_state->ascending_callback)
acpi_ps_parse_loop
acpi_ps_parse_aml
acpi_ps_execute_pass
acpi_ps_execute_method
acpi_ns_execute_control_method
acpi_ns_evaluate_by_handle
acpi_ev_execute_reg_method
Any suggestions/hints? I hope to get to the bottom of this in the next
few days.
Thanks.
--
Catalin
prev parent reply other threads:[~2006-06-02 9:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-28 10:31 Possible kernel memory leaks Catalin Marinas
2006-05-30 17:00 ` Catalin Marinas
2006-05-30 17:03 ` [PATCH] Fix the memory leak in acpi_evaluate_integer() Catalin Marinas
2006-05-31 13:47 ` Possible kernel memory leaks Catalin Marinas
2006-06-02 9:41 ` Catalin Marinas [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=tnx4pz3x5bi.fsf@arm.com \
--to=catalin.marinas@arm.com \
--cc=catalin.marinas@gmail.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.