Messages in this thread | | | From | Larry Finger <> | Subject | Possible memory leak in acpi_ut_create_internal_object_dbg() in 4.16-rcX | Date | Sun, 11 Mar 2018 21:58:22 -0500 |
| |
Running kernel 4.16-rcX, kmemleak complains about a leak of one object. This is linux-ubqc:~ # echo scan > /sys/kernel/debug/kmemleak linux-ubqc:~ # cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8802263b2630 (size 72): comm "swapper/0", pid 1, jiffies 4294892345 (age 8143.468s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 0e 14 01 00 00 05 00 00 ................ 00 00 00 00 00 00 00 00 b8 01 1d 26 02 88 ff ff ...........&.... backtrace: [<00000000a4d7a095>] acpi_ut_create_internal_object_dbg+0x4d/0x10e [<0000000091af3dcd>] acpi_ds_build_internal_object+0xed/0x1cd [<00000000c23098e0>] acpi_ds_build_internal_package_obj+0x1e6/0x32d [<00000000130427ae>] acpi_ds_eval_data_object_operands+0x178/0x218 [<0000000096a9eea7>] acpi_ds_exec_end_op+0x429/0x6b7 [<00000000bf84c466>] acpi_ps_parse_loop+0x919/0x9b1 [<0000000038521867>] acpi_ps_parse_aml+0x1a2/0x4af [<00000000f5588116>] acpi_ds_execute_arguments+0x184/0x1c3 [<000000004cdf7505>] acpi_ds_get_package_arguments+0xf8/0x124 [<00000000d3e97ad0>] acpi_ns_init_one_object+0xca/0x133 [<000000006c8e6828>] acpi_ns_walk_namespace+0x134/0x283 [<00000000d83f628d>] acpi_walk_namespace+0xf5/0x13d [<0000000031cfada2>] acpi_ns_initialize_objects+0x103/0x1fe [<00000000001d0e25>] acpi_initialize_objects+0x47/0xd4 [<000000005e2d42df>] acpi_init+0xc7/0x340 [<000000000ef98997>] do_one_initcall+0x4e/0x18d
Using gdb to find the offending source line returns:
99 /* Allocate the raw object descriptor */ 100 101 object = 102 acpi_ut_allocate_object_desc_dbg(module_name, line_number, 103 component_id); 104 if (!object) { 105 return_PTR(NULL); 106 } 107 108 switch (type) {
My suspicion is that this is a false positive, and a kmemleak_not_leak() call is likely appropriate, but that decision should be made at a higher level. I am not sure why kmemleak is triggering on this. Most of the relevant code is more than 10 years old.
Although leaking a single object is not serious, I prefer to eliminate it to ensure that every leak mentioned in the logs is something that I need to address. This is particularly important when I am debugging a driver.
Thanks,
Larry
| |