diff options
| author | Larry Finger <Larry.Finger@lwfinger.net> | 2018-05-12 09:59:38 -0500 |
|---|---|---|
| committer | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2018-05-27 12:23:03 +0200 |
| commit | 087ec15606b4a2ffef6fa3e2da4070e297f8b8f8 (patch) | |
| tree | fb260ce3e65247539518aac2f2d26ab196c784ff /drivers/acpi/acpica | |
| parent | dc689c5b336b9db9745654791f5cdf3ebbb54f4a (diff) | |
| download | linux-087ec15606b4a2ffef6fa3e2da4070e297f8b8f8.tar.gz linux-087ec15606b4a2ffef6fa3e2da4070e297f8b8f8.tar.bz2 linux-087ec15606b4a2ffef6fa3e2da4070e297f8b8f8.zip | |
ACPICA: Mark acpi_ut_create_internal_object_dbg() memory allocations as non-leaks
In kernel 4.17.0-rcX, kmemleak reports 9 leaks with tracebacks similar to
the following:
unreferenced object 0xffff880224a077e0 (size 72):
comm "swapper/0", pid 1, jiffies 4294892358 (age 1022.636s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 0e 01 01 00 00 00 00 01 ................
00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000004f506615>] acpi_ut_create_internal_object_dbg+0x4d/0x10e
[<000000006e7730e3>] acpi_ds_build_internal_object+0xed/0x1cd
[<00000000272b7c73>] acpi_ds_build_internal_package_obj+0x245/0x3a2
[<000000000b64c50e>] acpi_ds_eval_data_object_operands+0x17b/0x21b
[<00000000589647ac>] acpi_ds_exec_end_op+0x433/0x6c1
[<000000001d69bcbf>] acpi_ps_parse_loop+0x926/0x9be
[<000000005d6fa97d>] acpi_ps_parse_aml+0x1a2/0x4af
[<00000000c4bef823>] acpi_ps_execute_table+0xbb/0x119
[<00000000fd9632e4>] acpi_ns_execute_table+0x20c/0x260
[<00000000e6ae17ac>] acpi_ns_parse_table+0x7d/0x1b3
[<0000000008e1e148>] acpi_ns_load_table+0x8d/0x1c0
[<000000009fc8346f>] acpi_tb_load_namespace+0x176/0x278
[<0000000073f98b3b>] acpi_load_tables+0x6e/0xfd
[<00000000d2ef13d2>] acpi_init+0x8c/0x340
[<000000007da19d8d>] do_one_initcall+0x46/0x1fa
[<0000000024681a1d>] kernel_init_freeable+0x1a2/0x237
According to gdb, the offending code is
object =
acpi_ut_allocate_object_desc_dbg(module_name, line_number,
component_id);
As it is not possible to unload the ACPI code to test that this is a real
leak and not a false positive, and that only these 9 appear no matter how
long the system is up, a kmemleak_not_leak(object) call is inserted.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'drivers/acpi/acpica')
| -rw-r--r-- | drivers/acpi/acpica/utobject.c | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/drivers/acpi/acpica/utobject.c b/drivers/acpi/acpica/utobject.c index 5b78fe08d7d7..ae6d8cc18cec 100644 --- a/drivers/acpi/acpica/utobject.c +++ b/drivers/acpi/acpica/utobject.c @@ -8,6 +8,7 @@ *****************************************************************************/ #include <acpi/acpi.h> +#include <linux/kmemleak.h> #include "accommon.h" #include "acnamesp.h" @@ -70,6 +71,7 @@ union acpi_operand_object *acpi_ut_create_internal_object_dbg(const char if (!object) { return_PTR(NULL); } + kmemleak_not_leak(object); switch (type) { case ACPI_TYPE_REGION: |