Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Date:   Tue, 12 Dec 2023 13:13:47 +0800
From:   Kuan-Wei Chiu <visitorckw@gmail.com>
To:     Conor Dooley <conor.dooley@microchip.com>
Cc:     mturquette@baylibre.com, sboyd@kernel.org, duje.mihanovic@skole.hr,
        linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] clk: mmp: pxa168: Fix memory leak in pxa168_clk_init()
Message-ID: <ZXfsC3hpAWHiic3I@visitorckw-System-Product-Name>
References: <20231210175232.3414584-1-visitorckw@gmail.com>
 <20231211-urgent-carol-45ca352a9d2a@wendy>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231211-urgent-carol-45ca352a9d2a@wendy>
Precedence: bulk

On Mon, Dec 11, 2023 at 01:19:17PM +0000, Conor Dooley wrote:
> On Mon, Dec 11, 2023 at 01:52:32AM +0800, Kuan-Wei Chiu wrote:
> > In cases where mapping of mpmu/apmu/apbc registers fails, the code path
> > does not handle the failure gracefully, potentially leading to a memory
> > leak. This fix ensures proper cleanup by freeing the allocated memory
> > for 'pxa_unit' before returning.
> > 
> > Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> 
> I dunno why you have CCed me on this tbh, I guess I must have acked a
> patch related to this driver's bindings somehow.
>
I included you in the CC list based on the results from
./scripts/get_maintainer.pl, which listed your email. I apologize for
any inconvenience. I will be more careful in selecting the recipients
for my patches in the future.

> I wonder, is there actually any point in freeing these, isn't the system
> going to fail to actually boot if these allocations fail?
> 
I'm not familiar with the boot process. I noticed similar cleanup in
related code (e.g., clk-of-pxa1928.c) and thought it might be an
oversight in pxa168. If releasing memory here isn't essential, I'm
inclined to drop the patch.

However, if the cleanup is necessary, I believe additional iounmap,
similar to commit 19b9f29 (clk:mmp:clk-of-pxa910: Free memory and
Unmap region obtained by kzmalloc and of_iomap), may be required.
If necessary, I'm willing to send a v2 patch with the additional
changes.

Best regards,
Kuan-Wei Chiu
> > ---
> >  drivers/clk/mmp/clk-of-pxa168.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/clk/mmp/clk-of-pxa168.c b/drivers/clk/mmp/clk-of-pxa168.c
> > index fb0df64cf053..c5a7ba1deaa3 100644
> > --- a/drivers/clk/mmp/clk-of-pxa168.c
> > +++ b/drivers/clk/mmp/clk-of-pxa168.c
> > @@ -308,18 +308,21 @@ static void __init pxa168_clk_init(struct device_node *np)
> >  	pxa_unit->mpmu_base = of_iomap(np, 0);
> >  	if (!pxa_unit->mpmu_base) {
> >  		pr_err("failed to map mpmu registers\n");
> > +		kfree(pxa_unit);
> >  		return;
> >  	}
> >  
> >  	pxa_unit->apmu_base = of_iomap(np, 1);
> >  	if (!pxa_unit->apmu_base) {
> >  		pr_err("failed to map apmu registers\n");
> > +		kfree(pxa_unit);
> >  		return;
> >  	}
> >  
> >  	pxa_unit->apbc_base = of_iomap(np, 2);
> >  	if (!pxa_unit->apbc_base) {
> >  		pr_err("failed to map apbc registers\n");
> > +		kfree(pxa_unit);
> >  		return;
> >  	}
> >  
> > -- 
> > 2.25.1
> >