Hi
My qemu guest seems to be reporting now 46 memleaks ACPI related.
My kernel x86_64 - commit: 17d857be649a21ca90008c6dc425d849fa83db5c
(2.6.32-rc1)
unreferenced object 0xffff88001f8095d0 (size 8):
comm "swapper", pid 1, jiffies 4294877484
hex dump (first 8 bytes):
5c 00 80 1f 00 88 ff ff \.......
backtrace:
[<ffffffff8140a0c6>] kmemleak_alloc+0x26/0x60
[<ffffffff81128253>] __kmalloc+0x153/0x250
[<ffffffff812bfff5>] acpi_os_allocate+0x25/0x27
[<ffffffff812c0037>] acpi_ut_initialize_buffer+0x40/0x71
[<ffffffff812b739b>] acpi_ns_handle_to_pathname+0x3f/0xa7
[<ffffffff812b84c4>] acpi_get_name+0x45/0xb8
[<ffffffff8129b854>] acpi_bus_scan+0x3e/0xa0
[<ffffffff81878acd>] acpi_scan_init+0x45/0xba
[<ffffffff81878906>] acpi_init+0x21f/0x26a
[<ffffffff8100904c>] do_one_initcall+0x3c/0x1d0
[<ffffffff818574e6>] kernel_init+0x150/0x1a6
[<ffffffff8100d21a>] child_rip+0xa/0x20
[<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff88001fa13380 (size 128):
comm "swapper", pid 1, jiffies 4294877495
hex dump (first 32 bytes):
7d 00 00 00 50 43 49 30 06 00 00 00 00 0f 01 ff }...PCI0........
ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 ................
backtrace:
[<ffffffff8140a0c6>] kmemleak_alloc+0x26/0x60
[<ffffffff81128253>] __kmalloc+0x153/0x250
[<ffffffff812b829f>] acpi_get_object_info+0x161/0x341
[<ffffffff8129afcc>] acpi_add_single_object+0x2b8/0x9ca
[<ffffffff8129b7be>] acpi_bus_check_add+0xe0/0x138
[<ffffffff812b98b4>] acpi_ns_walk_namespace+0xb2/0x127
[<ffffffff812b6524>] acpi_walk_namespace+0x78/0xb2
[<ffffffff8129b89d>] acpi_bus_scan+0x87/0xa0
[<ffffffff81878acd>] acpi_scan_init+0x45/0xba
[<ffffffff81878906>] acpi_init+0x21f/0x26a
[<ffffffff8100904c>] do_one_initcall+0x3c/0x1d0
[<ffffffff818574e6>] kernel_init+0x150/0x1a6
[<ffffffff8100d21a>] child_rip+0xa/0x20
[<ffffffffffffffff>] 0xffffffffffffffff
....
All seems to be acpi_bus_scan() related.
Zdenek
On Tuesday 29 September 2009 03:18:53 am Zdenek Kabelac wrote:
> My qemu guest seems to be reporting now 46 memleaks ACPI related.
Thanks a lot for the report!
Can you verify that the patch below fixes these leaks?
commit fff7774a805e392ce258f0342e48cbe682ef2b9b
Author: Bjorn Helgaas <[email protected]>
Date: Tue Sep 29 10:32:19 2009 -0600
ACPI: fix bus scanning memory leaks
Free an acpi_get_object_info() buffer when we're finished. Skip the
acpi_get_name() altogether -- it was only used for a printk that was
really just for debug anyway.
Signed-off-by: Bjorn Helgaas <[email protected]>
Reported-by: Zdenek Kabelac <[email protected]>
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 468921b..14a7481 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1052,6 +1052,8 @@ static void acpi_device_set_id(struct acpi_device *device)
device->flags.bus_address = 1;
}
+ kfree(info);
+
/*
* Some devices don't reliably have _HIDs & _CIDs, so add
* synthetic HIDs to make sure drivers can find them.
@@ -1325,13 +1327,8 @@ static int acpi_bus_scan(acpi_handle handle, struct acpi_bus_ops *ops,
struct acpi_device **child)
{
acpi_status status;
- struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
void *device = NULL;
- acpi_get_name(handle, ACPI_FULL_PATHNAME, &buffer);
- printk(KERN_INFO PREFIX "Enumerating devices from [%s]\n",
- (char *) buffer.pointer);
-
status = acpi_bus_check_add(handle, 0, ops, &device);
if (ACPI_SUCCESS(status))
acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
2009/9/29 Bjorn Helgaas <[email protected]>:
> On Tuesday 29 September 2009 03:18:53 am Zdenek Kabelac wrote:
>> My qemu guest seems to be reporting now 46 memleaks ?ACPI related.
>
> Thanks a lot for the report!
>
> Can you verify that the patch below fixes these leaks?
>
Yes - leaks are fixed with this patch
>
> commit fff7774a805e392ce258f0342e48cbe682ef2b9b
> Author: Bjorn Helgaas <[email protected]>
> Date: ? Tue Sep 29 10:32:19 2009 -0600
>
> ? ?ACPI: fix bus scanning memory leaks
>
> ? ?Free an acpi_get_object_info() buffer when we're finished. ?Skip the
> ? ?acpi_get_name() altogether -- it was only used for a printk that was
> ? ?really just for debug anyway.
>
> ? ?Signed-off-by: Bjorn Helgaas <[email protected]>
> ? ?Reported-by: Zdenek Kabelac <[email protected]>
Reported-and-tested-by: Zdenek Kabelac <[email protected]>
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 468921b..14a7481 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -1052,6 +1052,8 @@ static void acpi_device_set_id(struct acpi_device *device)
> ? ? ? ? ? ? ? ? ? ? ? ?device->flags.bus_address = 1;
> ? ? ? ? ? ? ? ?}
>
> + ? ? ? ? ? ? ? kfree(info);
> +
> ? ? ? ? ? ? ? ?/*
> ? ? ? ? ? ? ? ? * Some devices don't reliably have _HIDs & _CIDs, so add
> ? ? ? ? ? ? ? ? * synthetic HIDs to make sure drivers can find them.
> @@ -1325,13 +1327,8 @@ static int acpi_bus_scan(acpi_handle handle, struct acpi_bus_ops *ops,
> ? ? ? ? ? ? ? ? ? ? ? ? struct acpi_device **child)
> ?{
> ? ? ? ?acpi_status status;
> - ? ? ? struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> ? ? ? ?void *device = NULL;
>
> - ? ? ? acpi_get_name(handle, ACPI_FULL_PATHNAME, &buffer);
> - ? ? ? printk(KERN_INFO PREFIX "Enumerating devices from [%s]\n",
> - ? ? ? ? ? ? ?(char *) buffer.pointer);
> -
> ? ? ? ?status = acpi_bus_check_add(handle, 0, ops, &device);
> ? ? ? ?if (ACPI_SUCCESS(status))
> ? ? ? ? ? ? ? ?acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
>
applied.
Zdenek, Bjorn,
Thanks for the quick testing & fix!
Len Brown, Intel Open Source Technology Center