LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [RFC] acpi: Declare memory allocations in acpi_ut_create_internal_object_dbg as non-leaks
@ 2018-05-12 14:59 Larry Finger
  2018-05-29  9:03 ` Rafael J. Wysocki
  0 siblings, 1 reply; 2+ messages in thread
From: Larry Finger @ 2018-05-12 14:59 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: linux-kernel, Larry Finger, Rafael J . Wysocki, Len Brown, linux-acpi

In kernel 4.17.0-rcX, kmemleak reports 9 leaks with tracebacks similat 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.

Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: linux-acpi@vger.kernel.org
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
 drivers/acpi/acpica/utobject.c | 2 ++
 1 file changed, 2 insertions(+)

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:
-- 
2.16.3

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [RFC] acpi: Declare memory allocations in acpi_ut_create_internal_object_dbg as non-leaks
  2018-05-12 14:59 [RFC] acpi: Declare memory allocations in acpi_ut_create_internal_object_dbg as non-leaks Larry Finger
@ 2018-05-29  9:03 ` Rafael J. Wysocki
  0 siblings, 0 replies; 2+ messages in thread
From: Rafael J. Wysocki @ 2018-05-29  9:03 UTC (permalink / raw)
  To: Larry Finger; +Cc: linux-kernel, linux-acpi, Erik Schmauss

On Saturday, May 12, 2018 4:59:38 PM CEST Larry Finger wrote:
> In kernel 4.17.0-rcX, kmemleak reports 9 leaks with tracebacks similat 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.
> 
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> Cc: Len Brown <lenb@kernel.org>
> Cc: linux-acpi@vger.kernel.org
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
>  drivers/acpi/acpica/utobject.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> 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:
> 

I've decided to apply this patch, thanks!

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-05-29  9:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-12 14:59 [RFC] acpi: Declare memory allocations in acpi_ut_create_internal_object_dbg as non-leaks Larry Finger
2018-05-29  9:03 ` Rafael J. Wysocki

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).