Possible memory leak in acpi_ut_create_internal_object_dbg() in 4.16-rcX

[Larry Finger]

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