[PATCH 1/1] mtd:nand:fix memory leak

Marc Gonzalez marc.w.gonzalez at free.fr
Thu Apr 5 02:12:11 PDT 2018


On 04/04/2018 09:08, Boris Brezillon wrote:

> On Wed, 4 Apr 2018 09:07:10 +0200
> Boris Brezillon <boris.brezillon at bootlin.com> wrote:
> 
>> On Wed, 4 Apr 2018 08:28:07 +0200
>> Miquel Raynal <miquel.raynal at bootlin.com> wrote:
>>
>>> Hi Xidong,
>>>
>>> As part of a reorganization in the NAND subsystem, you should now
>>> prefix your commit title this way:
>>>
>>>         mtd: rawnand: tango: fix memory leak
>>>
>>> Not sure if this patch is candidate to cc:stable?
>>>
>>> On Wed,  4 Apr 2018 11:05:51 +0800, Xidong Wang
>>> <wangxidong_97 at 163.com> wrote:
>>>   
>>>> In function tango_nand_probe(), the memory allocated by
>>>> clk_get() is not released on the normal path and
>>>> the error path that IS_ERR(nfc->chan) returns true.    
>>>
>>> The fact that the error path returns true looks out of topic, can you
>>> remove it? Just saying that you fix a memory leak is enough I guess.
>>>   
>>>> This will result in a memory leak bug.
>>>>
>>>> Signed-off-by: Xidong Wang <wangxidong_97 at 163.com>
>>>> ---
>>>>  drivers/mtd/nand/tango_nand.c | 5 ++++-
>>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/mtd/nand/tango_nand.c b/drivers/mtd/nand/tango_nand.c
>>>> index c5bee00b..8083459 100644
>>>> --- a/drivers/mtd/nand/tango_nand.c
>>>> +++ b/drivers/mtd/nand/tango_nand.c
>>>> @@ -648,12 +648,15 @@ static int tango_nand_probe(struct platform_device *pdev)
>>>>  		return PTR_ERR(clk);
>>>>  
>>>>  	nfc->chan = dma_request_chan(&pdev->dev, "rxtx");
>>>> -	if (IS_ERR(nfc->chan))
>>>> +	if (IS_ERR(nfc->chan)) {
>>>> +		clk_put(clk);
>>>>  		return PTR_ERR(nfc->chan);
>>>> +	}
>>>>  
>>>>  	platform_set_drvdata(pdev, nfc);
>>>>  	nand_hw_control_init(&nfc->hw);
>>>>  	nfc->freq_kHz = clk_get_rate(clk) / 1000;
>>>> +	clk_put(clk);    
>>>
>>> If the clock is used only here, better do the frequency derivation
>>> right after the clock_get(), and follow with a clk_put()? This way you
>>> don't have to change the error path and 'related' actions remain
>>> grouped.  
>>
>> Hm, definitely not a good idea to release the reference you have on the
>> clk if the driver depends on it. I recommend using devm_clk_get() to
>> solve this leak.
> 
> BTW, it's also weird that the driver does not prepare_enable the clk.
> Marc, any comments?

I was not aware that clk_get() allocated memory, and required clk_put()
for cleanup. IIRC, I looked at Documentation/clk.txt

On tango, clocks are configured by the boot loader. The existing clk driver
provides only read access to various clocks -- except the CPU clock, which
can be changed by tweaking a post-divider. Tweaking the PLLs requires much
more complex code. The boot loader enables every clock, and Linux has no
way to gate any of them.

In the nfc driver, all I needed was the system frequency, since the NFC is
driven by the system clock (which can never be disabled).

Thus, I wrote the naive (and apparently incorrect)

  clk = clk_get(&pdev->dev, NULL);
  nfc->freq_kHz = clk_get_rate(clk) / 1000;


I suppose the following patch would fix the memory leak, and
matches what Miquèl suggested.

Regards.


diff --git a/drivers/mtd/nand/tango_nand.c b/drivers/mtd/nand/tango_nand.c
index c5bee00b7f5e..fba162af333f 100644
--- a/drivers/mtd/nand/tango_nand.c
+++ b/drivers/mtd/nand/tango_nand.c
@@ -646,6 +646,8 @@ static int tango_nand_probe(struct platform_device *pdev)
        clk = clk_get(&pdev->dev, NULL);
        if (IS_ERR(clk))
                return PTR_ERR(clk);
+       nfc->freq_kHz = clk_get_rate(clk) / 1000;
+       clk_put(clk);
 
        nfc->chan = dma_request_chan(&pdev->dev, "rxtx");
        if (IS_ERR(nfc->chan))
@@ -653,7 +655,6 @@ static int tango_nand_probe(struct platform_device *pdev)
 
        platform_set_drvdata(pdev, nfc);
        nand_hw_control_init(&nfc->hw);
-       nfc->freq_kHz = clk_get_rate(clk) / 1000;
 
        for_each_child_of_node(pdev->dev.of_node, np) {
                err = chip_init(&pdev->dev, np);



More information about the linux-mtd mailing list