* [bug report] Memory leak from acpi_ev_install_space_handler() @ 2021-04-06 15:48 John Garry 2021-04-06 16:40 ` Rafael J. Wysocki 0 siblings, 1 reply; 5+ messages in thread From: John Garry @ 2021-04-06 15:48 UTC (permalink / raw) To: ACPI Devel Maling List, Len Brown, Rafael J. Wysocki; +Cc: linux-kernel Hi guys, On next-20210406, I enabled CONFIG_DEBUG_KMEMLEAK and CONFIG_DEBUG_TEST_DRIVER_REMOVE for my arm64 system, and see this: root@debian:/home/john# more /sys/kernel/debug/kmemleak unreferenced object 0xffff202803c11f00 (size 128): comm "swapper/0", pid 1, jiffies 4294894325 (age 337.524s) hex dump (first 32 bytes): 00 00 00 00 02 00 00 00 08 1f c1 03 28 20 ff ff............( .. 08 1f c1 03 28 20 ff ff 00 00 00 00 00 00 00 00....( .......... backtrace: [<00000000670a0938>] slab_post_alloc_hook+0x9c/0x2f8 [<00000000a3f47b39>] kmem_cache_alloc+0x198/0x2a8 [<000000002bdba864>] acpi_os_create_semaphore+0x54/0xe0 [<00000000bcd513fe>] acpi_ev_install_space_handler+0x24c/0x300 [<0000000002e116e2>] acpi_install_address_space_handler+0x64/0xb0 [<00000000ba00abc5>] i2c_acpi_install_space_handler+0xd4/0x138 [<000000008da42058>] i2c_register_adapter+0x368/0x910 [<00000000c03f7142>] i2c_add_adapter+0x9c/0x100 [<0000000000ba2fcf>] i2c_add_numbered_adapter+0x44/0x58 [<000000007df22d67>] i2c_dw_probe_master+0x68c/0x900 [<00000000682dfc98>] dw_i2c_plat_probe+0x460/0x640 [<00000000ad2dd3ee>] platform_probe+0x8c/0x108 [<00000000dd183e3f>] really_probe+0x190/0x670 [<0000000066017341>] driver_probe_device+0x8c/0xf8 [<00000000c441e843>] device_driver_attach+0x9c/0xa8 [<00000000f91dc709>] __driver_attach+0x88/0x138 unreferenced object 0xffff00280452c100 (size 128): comm "swapper/0", pid 1, jiffies 4294894558 (age 336.604s) hex dump (first 32 bytes): 00 00 00 00 02 00 00 00 08 c1 52 04 28 00 ff ff..........R.(... 08 c1 52 04 28 00 ff ff 00 00 00 00 00 00 00 00..R.(........... backtrace: [<00000000670a0938>] slab_post_alloc_hook+0x9c/0x2f8 [<00000000a3f47b39>] kmem_cache_alloc+0x198/0x2a8 [<000000002bdba864>] acpi_os_create_semaphore+0x54/0xe0 [<00000000bcd513fe>] acpi_ev_install_space_handler+0x24c/0x300 [<0000000002e116e2>] acpi_install_address_space_handler+0x64/0xb0 [<00000000988d4f61>] acpi_gpiochip_add+0x20c/0x4a0 [<0000000073d4faab>] gpiochip_add_data_with_key+0xd10/0x1680 [<000000001d50b98a>] devm_gpiochip_add_data_with_key+0x30/0x78 [<00000000fc3e7eaf>] dwapb_gpio_probe+0x828/0xb28 [<00000000ad2dd3ee>] platform_probe+0x8c/0x108 [<00000000dd183e3f>] really_probe+0x190/0x670 [<0000000066017341>] driver_probe_device+0x8c/0xf8 [<00000000c441e843>] device_driver_attach+0x9c/0xa8 [<00000000f91dc709>] __driver_attach+0x88/0x138 [<00000000d330caed>] bus_for_each_dev+0xec/0x160 [<00000000eebc5f04>] driver_attach+0x34/0x48 root@debian:/home/john# Thanks, John ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bug report] Memory leak from acpi_ev_install_space_handler() 2021-04-06 15:48 [bug report] Memory leak from acpi_ev_install_space_handler() John Garry @ 2021-04-06 16:40 ` Rafael J. Wysocki 2021-04-06 16:48 ` John Garry 0 siblings, 1 reply; 5+ messages in thread From: Rafael J. Wysocki @ 2021-04-06 16:40 UTC (permalink / raw) To: John Garry Cc: ACPI Devel Maling List, Len Brown, Rafael J. Wysocki, linux-kernel On Tue, Apr 6, 2021 at 5:51 PM John Garry <john.garry@huawei.com> wrote: > > Hi guys, > > On next-20210406, I enabled CONFIG_DEBUG_KMEMLEAK and > CONFIG_DEBUG_TEST_DRIVER_REMOVE for my arm64 system, and see this: Why exactly do you think that acpi_ev_install_space_handler() leaks memory? > root@debian:/home/john# more /sys/kernel/debug/kmemleak > unreferenced object 0xffff202803c11f00 (size 128): > comm "swapper/0", pid 1, jiffies 4294894325 (age 337.524s) > hex dump (first 32 bytes): > 00 00 00 00 02 00 00 00 08 1f c1 03 28 20 ff ff............( .. > 08 1f c1 03 28 20 ff ff 00 00 00 00 00 00 00 00....( .......... > backtrace: > [<00000000670a0938>] slab_post_alloc_hook+0x9c/0x2f8 > [<00000000a3f47b39>] kmem_cache_alloc+0x198/0x2a8 > [<000000002bdba864>] acpi_os_create_semaphore+0x54/0xe0 > [<00000000bcd513fe>] acpi_ev_install_space_handler+0x24c/0x300 > [<0000000002e116e2>] acpi_install_address_space_handler+0x64/0xb0 > [<00000000ba00abc5>] i2c_acpi_install_space_handler+0xd4/0x138 > [<000000008da42058>] i2c_register_adapter+0x368/0x910 > [<00000000c03f7142>] i2c_add_adapter+0x9c/0x100 > [<0000000000ba2fcf>] i2c_add_numbered_adapter+0x44/0x58 > [<000000007df22d67>] i2c_dw_probe_master+0x68c/0x900 > [<00000000682dfc98>] dw_i2c_plat_probe+0x460/0x640 > [<00000000ad2dd3ee>] platform_probe+0x8c/0x108 > [<00000000dd183e3f>] really_probe+0x190/0x670 > [<0000000066017341>] driver_probe_device+0x8c/0xf8 > [<00000000c441e843>] device_driver_attach+0x9c/0xa8 > [<00000000f91dc709>] __driver_attach+0x88/0x138 > unreferenced object 0xffff00280452c100 (size 128): > comm "swapper/0", pid 1, jiffies 4294894558 (age 336.604s) > hex dump (first 32 bytes): > 00 00 00 00 02 00 00 00 08 c1 52 04 28 00 ff ff..........R.(... > 08 c1 52 04 28 00 ff ff 00 00 00 00 00 00 00 00..R.(........... > backtrace: > [<00000000670a0938>] slab_post_alloc_hook+0x9c/0x2f8 > [<00000000a3f47b39>] kmem_cache_alloc+0x198/0x2a8 > [<000000002bdba864>] acpi_os_create_semaphore+0x54/0xe0 > [<00000000bcd513fe>] acpi_ev_install_space_handler+0x24c/0x300 > [<0000000002e116e2>] acpi_install_address_space_handler+0x64/0xb0 > [<00000000988d4f61>] acpi_gpiochip_add+0x20c/0x4a0 > [<0000000073d4faab>] gpiochip_add_data_with_key+0xd10/0x1680 > [<000000001d50b98a>] devm_gpiochip_add_data_with_key+0x30/0x78 > [<00000000fc3e7eaf>] dwapb_gpio_probe+0x828/0xb28 > [<00000000ad2dd3ee>] platform_probe+0x8c/0x108 > [<00000000dd183e3f>] really_probe+0x190/0x670 > [<0000000066017341>] driver_probe_device+0x8c/0xf8 > [<00000000c441e843>] device_driver_attach+0x9c/0xa8 > [<00000000f91dc709>] __driver_attach+0x88/0x138 > [<00000000d330caed>] bus_for_each_dev+0xec/0x160 > [<00000000eebc5f04>] driver_attach+0x34/0x48 > root@debian:/home/john# > > Thanks, > John ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bug report] Memory leak from acpi_ev_install_space_handler() 2021-04-06 16:40 ` Rafael J. Wysocki @ 2021-04-06 16:48 ` John Garry 2021-05-18 21:48 ` Kaneda, Erik 0 siblings, 1 reply; 5+ messages in thread From: John Garry @ 2021-04-06 16:48 UTC (permalink / raw) To: Rafael J. Wysocki Cc: ACPI Devel Maling List, Len Brown, Rafael J. Wysocki, linux-kernel On 06/04/2021 17:40, Rafael J. Wysocki wrote: > On Tue, Apr 6, 2021 at 5:51 PM John Garry <john.garry@huawei.com> wrote: >> >> Hi guys, >> >> On next-20210406, I enabled CONFIG_DEBUG_KMEMLEAK and >> CONFIG_DEBUG_TEST_DRIVER_REMOVE for my arm64 system, and see this: > Hi Rafael, > Why exactly do you think that acpi_ev_install_space_handler() leaks memory? > I don't think that acpi_ev_install_space_handler() itself leaks memory, but it seems that there is something missing in the code which is meant to undo/clean up after that on the uninstall path - I did make the point in writing "memory leak from", but maybe still not worded clearly. Anyway, I have not analyzed the problem fully - I'm just reporting. I don't mind looking further if requested. Thanks, John >> root@debian:/home/john# more /sys/kernel/debug/kmemleak >> unreferenced object 0xffff202803c11f00 (size 128): >> comm "swapper/0", pid 1, jiffies 4294894325 (age 337.524s) >> hex dump (first 32 bytes): >> 00 00 00 00 02 00 00 00 08 1f c1 03 28 20 ff ff............( .. >> 08 1f c1 03 28 20 ff ff 00 00 00 00 00 00 00 00....( .......... >> backtrace: >> [<00000000670a0938>] slab_post_alloc_hook+0x9c/0x2f8 >> [<00000000a3f47b39>] kmem_cache_alloc+0x198/0x2a8 >> [<000000002bdba864>] acpi_os_create_semaphore+0x54/0xe0 >> [<00000000bcd513fe>] acpi_ev_install_space_handler+0x24c/0x300 >> [<0000000002e116e2>] acpi_install_address_space_handler+0x64/0xb0 >> [<00000000ba00abc5>] i2c_acpi_install_space_handler+0xd4/0x138 >> [<000000008da42058>] i2c_register_adapter+0x368/0x910 >> [<00000000c03f7142>] i2c_add_adapter+0x9c/0x100 >> [<0000000000ba2fcf>] i2c_add_numbered_adapter+0x44/0x58 >> [<000000007df22d67>] i2c_dw_probe_master+0x68c/0x900 >> [<00000000682dfc98>] dw_i2c_plat_probe+0x460/0x640 >> [<00000000ad2dd3ee>] platform_probe+0x8c/0x108 >> [<00000000dd183e3f>] really_probe+0x190/0x670 >> [<0000000066017341>] driver_probe_device+0x8c/0xf8 >> [<00000000c441e843>] device_driver_attach+0x9c/0xa8 >> [<00000000f91dc709>] __driver_attach+0x88/0x138 >> unreferenced object 0xffff00280452c100 (size 128): >> comm "swapper/0", pid 1, jiffies 4294894558 (age 336.604s) >> hex dump (first 32 bytes): >> 00 00 00 00 02 00 00 00 08 c1 52 04 28 00 ff ff..........R.(... >> 08 c1 52 04 28 00 ff ff 00 00 00 00 00 00 00 00..R.(........... >> backtrace: >> [<00000000670a0938>] slab_post_alloc_hook+0x9c/0x2f8 >> [<00000000a3f47b39>] kmem_cache_alloc+0x198/0x2a8 >> [<000000002bdba864>] acpi_os_create_semaphore+0x54/0xe0 >> [<00000000bcd513fe>] acpi_ev_install_space_handler+0x24c/0x300 >> [<0000000002e116e2>] acpi_install_address_space_handler+0x64/0xb0 >> [<00000000988d4f61>] acpi_gpiochip_add+0x20c/0x4a0 >> [<0000000073d4faab>] gpiochip_add_data_with_key+0xd10/0x1680 >> [<000000001d50b98a>] devm_gpiochip_add_data_with_key+0x30/0x78 >> [<00000000fc3e7eaf>] dwapb_gpio_probe+0x828/0xb28 >> [<00000000ad2dd3ee>] platform_probe+0x8c/0x108 >> [<00000000dd183e3f>] really_probe+0x190/0x670 >> [<0000000066017341>] driver_probe_device+0x8c/0xf8 >> [<00000000c441e843>] device_driver_attach+0x9c/0xa8 >> [<00000000f91dc709>] __driver_attach+0x88/0x138 >> [<00000000d330caed>] bus_for_each_dev+0xec/0x160 >> [<00000000eebc5f04>] driver_attach+0x34/0x48 >> root@debian:/home/john# >> >> Thanks, >> John > . > ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [bug report] Memory leak from acpi_ev_install_space_handler() 2021-04-06 16:48 ` John Garry @ 2021-05-18 21:48 ` Kaneda, Erik 2021-05-19 8:20 ` John Garry 0 siblings, 1 reply; 5+ messages in thread From: Kaneda, Erik @ 2021-05-18 21:48 UTC (permalink / raw) To: John Garry, Rafael J. Wysocki Cc: ACPI Devel Maling List, Len Brown, Rafael J. Wysocki, linux-kernel > -----Original Message----- > From: John Garry <john.garry@huawei.com> > Sent: Tuesday, April 6, 2021 9:48 AM > To: Rafael J. Wysocki <rafael@kernel.org> > Cc: ACPI Devel Maling List <linux-acpi@vger.kernel.org>; Len Brown > <lenb@kernel.org>; Rafael J. Wysocki <rjw@rjwysocki.net>; linux- > kernel@vger.kernel.org > Subject: Re: [bug report] Memory leak from acpi_ev_install_space_handler() > > On 06/04/2021 17:40, Rafael J. Wysocki wrote: > > On Tue, Apr 6, 2021 at 5:51 PM John Garry <john.garry@huawei.com> > wrote: > >> > >> Hi guys, > >> > >> On next-20210406, I enabled CONFIG_DEBUG_KMEMLEAK and > >> CONFIG_DEBUG_TEST_DRIVER_REMOVE for my arm64 system, and see > this: > > > > Hi Rafael, > > > Why exactly do you think that acpi_ev_install_space_handler() leaks > memory? > > > > I don't think that acpi_ev_install_space_handler() itself leaks memory, > but it seems that there is something missing in the code which is meant > to undo/clean up after that on the uninstall path - I did make the point > in writing "memory leak from", but maybe still not worded clearly. > > Anyway, I have not analyzed the problem fully - I'm just reporting. > Hi John, > I don't mind looking further if requested. Someone else reported this as well. Could you try the patch below? I think it might help fix this issue.. Thanks, Erik diff --git a/drivers/acpi/acpica/utdelete.c b/drivers/acpi/acpica/utdelete.c index 624a26794d55..e5ba9795ec69 100644 --- a/drivers/acpi/acpica/utdelete.c +++ b/drivers/acpi/acpica/utdelete.c @@ -285,6 +285,14 @@ static void acpi_ut_delete_internal_obj(union acpi_operand_object *object) } break; + case ACPI_TYPE_LOCAL_ADDRESS_HANDLER: + + ACPI_DEBUG_PRINT((ACPI_DB_ALLOCATIONS, + "***** Address handler %p\n", object)); + + acpi_os_delete_mutex(object->address_space.context_mutex); + break; + default: break; > > Thanks, > John > > >> root@debian:/home/john# more /sys/kernel/debug/kmemleak > >> unreferenced object 0xffff202803c11f00 (size 128): > >> comm "swapper/0", pid 1, jiffies 4294894325 (age 337.524s) > >> hex dump (first 32 bytes): > >> 00 00 00 00 02 00 00 00 08 1f c1 03 28 20 ff ff............( .. > >> 08 1f c1 03 28 20 ff ff 00 00 00 00 00 00 00 00....( .......... > >> backtrace: > >> [<00000000670a0938>] slab_post_alloc_hook+0x9c/0x2f8 > >> [<00000000a3f47b39>] kmem_cache_alloc+0x198/0x2a8 > >> [<000000002bdba864>] acpi_os_create_semaphore+0x54/0xe0 > >> [<00000000bcd513fe>] acpi_ev_install_space_handler+0x24c/0x300 > >> [<0000000002e116e2>] acpi_install_address_space_handler+0x64/0xb0 > >> [<00000000ba00abc5>] i2c_acpi_install_space_handler+0xd4/0x138 > >> [<000000008da42058>] i2c_register_adapter+0x368/0x910 > >> [<00000000c03f7142>] i2c_add_adapter+0x9c/0x100 > >> [<0000000000ba2fcf>] i2c_add_numbered_adapter+0x44/0x58 > >> [<000000007df22d67>] i2c_dw_probe_master+0x68c/0x900 > >> [<00000000682dfc98>] dw_i2c_plat_probe+0x460/0x640 > >> [<00000000ad2dd3ee>] platform_probe+0x8c/0x108 > >> [<00000000dd183e3f>] really_probe+0x190/0x670 > >> [<0000000066017341>] driver_probe_device+0x8c/0xf8 > >> [<00000000c441e843>] device_driver_attach+0x9c/0xa8 > >> [<00000000f91dc709>] __driver_attach+0x88/0x138 > >> unreferenced object 0xffff00280452c100 (size 128): > >> comm "swapper/0", pid 1, jiffies 4294894558 (age 336.604s) > >> hex dump (first 32 bytes): > >> 00 00 00 00 02 00 00 00 08 c1 52 04 28 00 ff ff..........R.(... > >> 08 c1 52 04 28 00 ff ff 00 00 00 00 00 00 00 00..R.(........... > >> backtrace: > >> [<00000000670a0938>] slab_post_alloc_hook+0x9c/0x2f8 > >> [<00000000a3f47b39>] kmem_cache_alloc+0x198/0x2a8 > >> [<000000002bdba864>] acpi_os_create_semaphore+0x54/0xe0 > >> [<00000000bcd513fe>] acpi_ev_install_space_handler+0x24c/0x300 > >> [<0000000002e116e2>] acpi_install_address_space_handler+0x64/0xb0 > >> [<00000000988d4f61>] acpi_gpiochip_add+0x20c/0x4a0 > >> [<0000000073d4faab>] gpiochip_add_data_with_key+0xd10/0x1680 > >> [<000000001d50b98a>] devm_gpiochip_add_data_with_key+0x30/0x78 > >> [<00000000fc3e7eaf>] dwapb_gpio_probe+0x828/0xb28 > >> [<00000000ad2dd3ee>] platform_probe+0x8c/0x108 > >> [<00000000dd183e3f>] really_probe+0x190/0x670 > >> [<0000000066017341>] driver_probe_device+0x8c/0xf8 > >> [<00000000c441e843>] device_driver_attach+0x9c/0xa8 > >> [<00000000f91dc709>] __driver_attach+0x88/0x138 > >> [<00000000d330caed>] bus_for_each_dev+0xec/0x160 > >> [<00000000eebc5f04>] driver_attach+0x34/0x48 > >> root@debian:/home/john# > >> > >> Thanks, > >> John > > . > > ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [bug report] Memory leak from acpi_ev_install_space_handler() 2021-05-18 21:48 ` Kaneda, Erik @ 2021-05-19 8:20 ` John Garry 0 siblings, 0 replies; 5+ messages in thread From: John Garry @ 2021-05-19 8:20 UTC (permalink / raw) To: Kaneda, Erik, Rafael J. Wysocki Cc: ACPI Devel Maling List, Len Brown, Rafael J. Wysocki, linux-kernel, chenxiang On 18/05/2021 22:48, Kaneda, Erik wrote: > Hi John, > >> I don't mind looking further if requested. > Someone else reported this as well. I noticed. By chance, it was my close colleague Xiang Chen. Could you try the patch below? I think it might help fix this issue.. It looks like the same problem, and you provided the same solution, so we can look to test it. Thanks > > Thanks, > Erik > > diff --git a/drivers/acpi/acpica/utdelete.c b/drivers/acpi/acpica/utdelete.c > index 624a26794d55..e5ba9795ec69 100644 > --- a/drivers/acpi/acpica/utdelete.c > +++ b/drivers/acpi/acpica/utdelete.c > @@ -285,6 +285,14 @@ static void acpi_ut_delete_internal_obj(union acpi_operand_object *object) > } > break; > > + case ACPI_TYPE_LOCAL_ADDRESS_HANDLER: > + > + ACPI_DEBUG_PRINT((ACPI_DB_ALLOCATIONS, > + "***** Address handler %p\n", object)); > + > + acpi_os_delete_mutex(object->address_space.context_mutex); > + break; > + > default: > > break; > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-05-19 8:21 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-04-06 15:48 [bug report] Memory leak from acpi_ev_install_space_handler() John Garry 2021-04-06 16:40 ` Rafael J. Wysocki 2021-04-06 16:48 ` John Garry 2021-05-18 21:48 ` Kaneda, Erik 2021-05-19 8:20 ` John Garry
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).