[linux-yocto] [PATCH 1/1] clk: zynqmp: fix memory leak in zynqmp_register_clocks

[Quanyang Wang]

Hi MIchal,

The steps are:

(1)

I use kernel source https://github.com/Xilinx/linux-xlnx.git 
xlnx_rebase_v4.19.

(2)

Enable kernel option:

Kernel hacking  ---> Memory Debugging  --->

[*] Kernel memory leak detector

(9000) Maximum kmemleak early log entries.

(3)

When the board boots, run the command as below:

echo scan > /sys/kernel/debug/kmemleak

Then cat /sys/kernel/debug/kmemleak.


I attached the log as zcu102.log. Using mainline and linux-yocto with 
enabling kmemleak can also reproduce the memory leak.

Thanks,

Quanyang

On 10/18/19 2:33 PM, Michal Simek wrote:
> Hi,
>
> On 16. 10. 19 15:02, quanyang.wang at windriver.com wrote:
>> From: Quanyang Wang <quanyang.wang at windriver.com>
>>
>> This is detected by kmemleak running on zcu102 board:
>>
>> unreferenced object 0xffffffc877e48180 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294892909 (age 315.436s)
>> hex dump (first 32 bytes):
>> 64 70 5f 76 69 64 65 6f 5f 72 65 66 5f 64 69 76 dp_video_ref_div
>> 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1...............
>> backtrace:
>> [<00000000c9be883b>] __kmalloc_track_caller+0x200/0x380
>> [<00000000f02c3809>] kvasprintf+0x7c/0x100
>> [<00000000e51dde4d>] kasprintf+0x60/0x80
>> [<0000000092298b05>] zynqmp_register_clocks+0x29c/0x398
>> [<00000000faaff182>] zynqmp_clock_probe+0x3cc/0x4c0
>> [<000000005f5986f0>] platform_drv_probe+0x58/0xa8
>> [<00000000d5810136>] really_probe+0xd8/0x2a8
>> [<00000000f5b671be>] driver_probe_device+0x5c/0x100
>> [<0000000038f91fcf>] __device_attach_driver+0x98/0xb8
>> [<000000008a3f2ac2>] bus_for_each_drv+0x74/0xd8
>> [<000000001cb2783d>] __device_attach+0xe0/0x140
>> [<00000000c268031b>] device_initial_probe+0x24/0x30
>> [<000000006998de4b>] bus_probe_device+0x9c/0xa8
>> [<00000000647ae6ff>] device_add+0x3c0/0x610
>> [<0000000071c14bb8>] of_device_add+0x40/0x50
>> [<000000004bb5d132>] of_platform_device_create_pdata+0xbc/0x138
>>
>> This is because that when num_nodes is larger than 1, clk_out is
>> allocated using kasprintf for these nodes but only the last node's
>> clk_out is freed.
>>
>> Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
>> ---
>>   drivers/clk/zynqmp/clkc.c | 16 ++++++++++------
>>   1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/clk/zynqmp/clkc.c b/drivers/clk/zynqmp/clkc.c
>> index 64355fd07f6b..536f68c98e97 100644
>> --- a/drivers/clk/zynqmp/clkc.c
>> +++ b/drivers/clk/zynqmp/clkc.c
>> @@ -563,7 +563,7 @@ static struct clk_hw *zynqmp_register_clk_topology(int clk_id, char *clk_name,
>>   {
>>   	int j;
>>   	u32 num_nodes, clk_dev_id;
>> -	char *clk_out = NULL;
>> +	char *clk_out[MAX_NODES];
>>   	struct clock_topology *nodes;
>>   	struct clk_hw *hw = NULL;
>>   
>> @@ -577,16 +577,16 @@ static struct clk_hw *zynqmp_register_clk_topology(int clk_id, char *clk_name,
>>   		 * Intermediate clock names are postfixed with type of clock.
>>   		 */
>>   		if (j != (num_nodes - 1)) {
>> -			clk_out = kasprintf(GFP_KERNEL, "%s%s", clk_name,
>> +			clk_out[j] = kasprintf(GFP_KERNEL, "%s%s", clk_name,
>>   					    clk_type_postfix[nodes[j].type]);
>>   		} else {
>> -			clk_out = kasprintf(GFP_KERNEL, "%s", clk_name);
>> +			clk_out[j] = kasprintf(GFP_KERNEL, "%s", clk_name);
>>   		}
>>   
>>   		if (!clk_topology[nodes[j].type])
>>   			continue;
>>   
>> -		hw = (*clk_topology[nodes[j].type])(clk_out, clk_dev_id,
>> +		hw = (*clk_topology[nodes[j].type])(clk_out[j], clk_dev_id,
>>   						    parent_names,
>>   						    num_parents,
>>   						    &nodes[j]);
>> @@ -595,9 +595,12 @@ static struct clk_hw *zynqmp_register_clk_topology(int clk_id, char *clk_name,
>>   				     __func__,  clk_dev_id, clk_name,
>>   				     PTR_ERR(hw));
>>   
>> -		parent_names[0] = clk_out;
>> +		parent_names[0] = clk_out[j];
>>   	}
>> -	kfree(clk_out);
>> +
>> +	for (j = 0; j < num_nodes; j++)
>> +		kfree(clk_out[j]);
>> +
>>   	return hw;
>>   }
>>   
>>
> I have tried to replicated but didn't see this issue. Can you please
> send me full boot log with steps you have done?
>
> Thanks,
> Michal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zcu102.log
Type: text/x-log
Size: 36667 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/linux-yocto/attachments/20191018/ff8c6be1/attachment-0001.bin>