From: "Catalin Marinas" <catalin.marinas@gmail.com>
To: "Ingo Molnar" <mingo@elte.hu>
Cc: "Pekka Enberg" <penberg@cs.helsinki.fi>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.17-rc6 7/9] Remove some of the kmemleak false positives
Date: Sat, 24 Jun 2006 11:55:26 +0100 [thread overview]
Message-ID: <b0943d9e0606240355u69818bf8n657af686a0f6a380@mail.gmail.com> (raw)
In-Reply-To: <20060624102248.GA23277@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]
On 24/06/06, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Catalin Marinas <catalin.marinas@gmail.com> wrote:
> > To the other extreme is Ingo's suggestion of using exact type
> > identification but I don't think this would be acceptable for the
> > kernel as it would to modify all the memory alloc calls in the kernel
> > to either pass an additional parameter (the type id) or another
> > post-allocation call to kmemleak to update the id.
>
> passing in the type ID wouldnt be that bad and it would have other
> advantages as well: for example we could do strict type-checking of
> allocation size versus type-we-use-it-for.
There are valid places in the kernel where the allocated size is
different from the type's one. That's why I added the
memleak_padding().
> As long as the conversion is gradual i think we could try this. I.e.
> we'd default to 'no ID passed', and in that case we would fall back to
> the size-based method and generate an ID out of the structure size.
OK, I'll try to add the infrastructure for type ids but default to
sizeof initially.
> > Anyway, the current implementation (I'll update it for 2.6.17) detects
> > real memory leaks. I suspect that a wide range of leaks would be
> > covered if it is used on different platforms and different conditions.
>
> btw., what leaks were found so far? I know about the ACPI one - any
> other ones?
There are two leaks reported in ACPI but I only posted a patch for one
as I didn't have time to track the other (a reference count doesn't
get to zero and the structure not freed).
There is another leak in legacy_init_iomem_resources() in
arch/i386/setup.c (request_resource() fails but the memory is not
freed - see the attached patch). I initially marked this as a false
positive but it wasn't (I have to revisit the false positives).
--
Catalin
[-- Attachment #2: i386-setup-leak.patch --]
[-- Type: text/x-patch, Size: 835 bytes --]
Fix a memory leak in the i386 setup code
From: Catalin Marinas <catalin.marinas@gmail.com>
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
arch/i386/kernel/setup.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c
index dd6b0e3..60f5d99 100644
--- a/arch/i386/kernel/setup.c
+++ b/arch/i386/kernel/setup.c
@@ -1332,7 +1332,10 @@ legacy_init_iomem_resources(struct resou
res->start = e820.map[i].addr;
res->end = res->start + e820.map[i].size - 1;
res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
- request_resource(&iomem_resource, res);
+ if (request_resource(&iomem_resource, res)) {
+ kfree(res);
+ continue;
+ }
if (e820.map[i].type == E820_RAM) {
/*
* We don't know which RAM region contains kernel data,
next prev parent reply other threads:[~2006-06-24 10:55 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-11 11:18 [PATCH 2.6.17-rc6 0/9] Kernel memory leak detector 0.7 Catalin Marinas
2006-06-11 11:21 ` [PATCH 2.6.17-rc6 1/9] Base support for kmemleak Catalin Marinas
2006-06-13 11:14 ` Pekka Enberg
2006-06-13 12:47 ` Catalin Marinas
2006-06-11 11:21 ` [PATCH 2.6.17-rc6 2/9] Some documentation " Catalin Marinas
2006-06-11 11:21 ` [PATCH 2.6.17-rc6 3/9] Add the memory allocation/freeing hooks " Catalin Marinas
2006-06-11 11:21 ` [PATCH 2.6.17-rc6 4/9] Modules support " Catalin Marinas
2006-06-11 11:21 ` [PATCH 2.6.17-rc6 5/9] Add kmemleak support for i386 Catalin Marinas
2006-06-11 11:21 ` [PATCH 2.6.17-rc6 6/9] Add kmemleak support for ARM Catalin Marinas
2006-06-11 11:21 ` [PATCH 2.6.17-rc6 7/9] Remove some of the kmemleak false positives Catalin Marinas
2006-06-12 5:19 ` Pekka Enberg
2006-06-12 8:11 ` Catalin Marinas
2006-06-12 8:17 ` Pekka J Enberg
2006-06-12 8:43 ` Catalin Marinas
2006-06-12 10:53 ` Ingo Molnar
2006-06-12 11:08 ` Pekka J Enberg
2006-06-12 11:36 ` Ingo Molnar
2006-06-12 11:56 ` Pekka J Enberg
2006-06-12 12:53 ` Catalin Marinas
2006-06-12 13:12 ` Ingo Molnar
2006-06-12 14:38 ` Catalin Marinas
2006-06-12 22:29 ` Catalin Marinas
2006-06-12 12:56 ` Catalin Marinas
2006-06-12 19:22 ` Ingo Molnar
2006-06-12 22:24 ` Catalin Marinas
2006-06-13 5:53 ` Pekka J Enberg
2006-06-13 6:59 ` Catalin Marinas
2006-06-13 7:57 ` Pekka J Enberg
2006-06-13 9:45 ` Catalin Marinas
2006-06-13 10:04 ` Pekka Enberg
2006-06-13 10:37 ` Catalin Marinas
2006-06-13 7:26 ` Ingo Molnar
2006-06-13 8:11 ` Pekka J Enberg
2006-06-13 10:49 ` Catalin Marinas
2006-06-14 4:07 ` Ingo Molnar
2006-06-14 5:46 ` Andi Kleen
2006-06-14 5:53 ` Jeremy Fitzhardinge
2006-06-14 12:03 ` Ingo Molnar
2006-06-14 13:46 ` Catalin Marinas
2006-06-14 13:35 ` Catalin Marinas
2006-06-14 13:21 ` Catalin Marinas
2006-06-12 9:17 ` Peter Zijlstra
2006-06-12 9:35 ` Catalin Marinas
2006-06-24 10:20 ` Catalin Marinas
2006-06-24 10:22 ` Ingo Molnar
2006-06-24 10:55 ` Catalin Marinas [this message]
2006-07-24 11:15 ` Ingo Molnar
2006-07-24 13:28 ` Catalin Marinas
2006-08-03 6:32 ` Jakub Jelinek
2006-08-03 8:31 ` Catalin Marinas
2006-06-11 11:22 ` [PATCH 2.6.17-rc6 8/9] Simple testing for kmemleak Catalin Marinas
2006-06-11 11:22 ` [PATCH 2.6.17-rc6 9/9] Keep the __init functions after initialization Catalin Marinas
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=b0943d9e0606240355u69818bf8n657af686a0f6a380@mail.gmail.com \
--to=catalin.marinas@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=penberg@cs.helsinki.fi \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®