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
