From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catalin Marinas Subject: Re: Possible kernel memory leaks Date: Wed, 31 May 2006 14:47:35 +0100 Message-ID: References: <44797BEF.70206@gmail.com> Reply-To: Catalin Marinas Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from cam-admin0.cambridge.arm.com ([193.131.176.58]:37869 "EHLO cam-admin0.cambridge.arm.com") by vger.kernel.org with ESMTP id S965017AbWEaNrk (ORCPT ); Wed, 31 May 2006 09:47:40 -0400 In-Reply-To: <44797BEF.70206@gmail.com> (Catalin Marinas's message of "Sun, 28 May 2006 11:31:11 +0100") Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org Catalin Marinas 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: > c01ffa07: > c0215b3a: > c02159ce: > c0203784: > c0203db4: > c020ed17: > c0203d6b: > 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