Memory leak reported for hikey960 with kmemleak on 4.9


#1

I am facing the following memory leak on hikey960 reported through kmemleak while booted with 4.9 kernel:

{{{
unreferenced object 0xffffffc0b27ae800 (size 128):
comm “swapper/0”, pid 1, jiffies 4294892809 (age 518.288s)
hex dump (first 32 bytes):
01 00 00 00 00 00 01 00 00 00 01 01 00 00 00 00 …
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
backtrace:
[] create_object+0x110/0x288
[] kmemleak_alloc+0x58/0xa0
[] __kmalloc+0x254/0x2f0
[] psci_cpu_init_idle+0x9c/0x2b0
[] acpi_processor_ffh_lpi_probe+0x40/0x58
[] arm_cpuidle_init+0x20/0x30
[] hisi_idle_drv_init+0x8c/0xe0
[] hisi_idle_init+0x44/0x104
[] do_one_initcall+0x44/0x138
[] kernel_init_freeable+0x1c0/0x264
[] kernel_init+0x18/0x108
[] ret_from_fork+0x10/0x50
[] 0xffffffffffffffff
}}}

  • The unreferenced object is found in drivers/firmware/psci.c
  • The memory for psci_states is freed in case of error paths, but not in the normal flow. Deallocating it doesn’t make sense as I’m pretty sure it is used later on at some point in time.

Marking the object as kmemleak_not_leak fixes the issue, but I’m not sure it is the legitimate fix.
{{{
diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index 8263429…9a829bc 100644
— a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -297,6 +297,7 @@ static int psci_dt_cpu_init_idle(struct device_node cpu_node, int cpu)
}
/
Idle states parsed correctly, initialize per-cpu pointer */
per_cpu(psci_power_state, cpu) = psci_states;

  •   kmemleak_not_leak(psci_states);
      return 0;
    

free_mem:
@@ -343,6 +344,7 @@ static int __maybe_unused psci_acpi_cpu_init_idle(unsigned int cpu)
}
/* Idle states parsed correctly, initialize per-cpu pointer */
per_cpu(psci_power_state, cpu) = psci_states;

  •   kmemleak_not_leak(psci_states);
      return 0;
    

}
#else
}}}

Has anyone faced this issue before? Or could anyone reproduce the issue and confirm?


#2

Thanks for reporting, actually psci_states memory is only allocated at init with no balanced memory release… I assume this causes the kmemleak report. However, because memory is used during all runtime life, the leak never happens. Since there is no symmetric function (cpu_deinit_idle), I think your patch makes sense. I suggest you to propose this patch upstream via android gerrit server or opening a bug with your patch attached.


#3

Thank you for your quick input @Loic, I will look into it. :slight_smile: