hd44780_probe() allocates a memory chunk for hd with kzalloc() and
makes "lcd->drvdata->hd44780" point to it. When we call hd44780_remove(),
we should release all relevant memory and resource. But "lcd->drvdata
->hd44780" is not released, which will lead to a memory leak.

We should release the "lcd->drvdata->hd44780" in hd44780_remove() to fix
the memory leak bug.

Fixes: 41c8d0adf3c4 ("auxdisplay: hd44780: Fix memory leak on ->remove()")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Jianglei Nie <niejianglei2021@163.com>
---
 drivers/auxdisplay/hd44780.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/auxdisplay/hd44780.c b/drivers/auxdisplay/hd44780.c
index 8b2a0eb3f32a..f4800a946bd8 100644
--- a/drivers/auxdisplay/hd44780.c
+++ b/drivers/auxdisplay/hd44780.c
@@ -322,8 +322,10 @@ static int hd44780_probe(struct platform_device *pdev)
 static int hd44780_remove(struct platform_device *pdev)
 {
 	struct charlcd *lcd = platform_get_drvdata(pdev);
+	struct hd44780_common *hdc = (struct hd44780_common *)lcd->drvdata;
 
 	charlcd_unregister(lcd);
+	kfree(hdc->hd44780);
 	kfree(lcd->drvdata);
 
 	kfree(lcd);
-- 
2.25.1

On Mon, Nov 28, 2022 at 04:44:21PM +0800, Jianglei Nie wrote:
> hd44780_probe() allocates a memory chunk for hd with kzalloc() and
> makes "lcd->drvdata->hd44780" point to it. When we call hd44780_remove(),
> we should release all relevant memory and resource. But "lcd->drvdata
> ->hd44780" is not released, which will lead to a memory leak.
> 
> We should release the "lcd->drvdata->hd44780" in hd44780_remove() to fix
> the memory leak bug.

Better now! See my comments below. After addressing them,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

> Fixes: 41c8d0adf3c4 ("auxdisplay: hd44780: Fix memory leak on ->remove()")

Fixes: 718e05ed92ec ("auxdisplay: Introduce hd44780_common.[ch]")

What you found has nothing to do with the issue. Issue has been introduced
later on.

> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Jianglei Nie <niejianglei2021@163.com>
> ---
>  drivers/auxdisplay/hd44780.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/auxdisplay/hd44780.c b/drivers/auxdisplay/hd44780.c
> index 8b2a0eb3f32a..f4800a946bd8 100644
> --- a/drivers/auxdisplay/hd44780.c
> +++ b/drivers/auxdisplay/hd44780.c
> @@ -322,8 +322,10 @@ static int hd44780_probe(struct platform_device *pdev)
>  static int hd44780_remove(struct platform_device *pdev)
>  {
>  	struct charlcd *lcd = platform_get_drvdata(pdev);

> +	struct hd44780_common *hdc = (struct hd44780_common *)lcd->drvdata;

drvdata member is type of void *, no need to do an explicit casting as
per C standard.

>  	charlcd_unregister(lcd);
> +	kfree(hdc->hd44780);
>  	kfree(lcd->drvdata);
>  
>  	kfree(lcd);
> -- 
> 2.25.1
> 

-- 
With Best Regards,
Andy Shevchenko

On Mon, Nov 28, 2022 at 12:45:39PM +0200, Andy Shevchenko wrote:
> On Mon, Nov 28, 2022 at 04:44:21PM +0800, Jianglei Nie wrote:

...

> Fixes: 718e05ed92ec ("auxdisplay: Introduce hd44780_common.[ch]")
> 
> What you found has nothing to do with the issue. Issue has been introduced
> later on.

Side note (mostly for Miguel): That series by Lars was indeed problematic.
And I see now that he didn't get the parameter to the charlcd_alloc(). Now
we have problem that your patch solves and dangling parameter in the struct
charlcd_priv. So, I will restore charlcd_alloc() before his series (after
this patch has been applied, because of the backport needs) for a new
kernel development cycle.

-- 
With Best Regards,
Andy Shevchenko

On Mon, Nov 28, 2022 at 12:59:28PM +0200, Andy Shevchenko wrote:
> On Mon, Nov 28, 2022 at 12:45:39PM +0200, Andy Shevchenko wrote:
> > On Mon, Nov 28, 2022 at 04:44:21PM +0800, Jianglei Nie wrote:

...

> > Fixes: 718e05ed92ec ("auxdisplay: Introduce hd44780_common.[ch]")
> > 
> > What you found has nothing to do with the issue. Issue has been introduced
> > later on.
> 
> Side note (mostly for Miguel): That series by Lars was indeed problematic.
> And I see now that he didn't get the parameter to the charlcd_alloc(). Now
> we have problem that your patch solves and dangling parameter in the struct
> charlcd_priv. So, I will restore charlcd_alloc() before his series (after
> this patch has been applied, because of the backport needs) for a new
> kernel development cycle.

FWIW, the
https://lore.kernel.org/r/20250224173010.219024-1-andriy.shevchenko@linux.intel.com
has been just sent.

-- 
With Best Regards,
Andy Shevchenko