Received-SPF: pass (google.com: domain of linux-kernel+bounces-160079-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>
Date: Fri, 26 Apr 2024 16:45:06 +0300 (EEST)
To: lumingyindetect@126.com
cc: LKML <linux-kernel@vger.kernel.org>, 
    linux-serial <linux-serial@vger.kernel.org>, 
    Andy Shevchenko <andriy.shevchenko@linux.intel.com>, 
    Greg Kroah-Hartman <gregkh@linuxfoundation.org>, 
    Jiri Slaby <jirislaby@kernel.org>, 
    LuMingYin <11570291+yin-luming@user.noreply.gitee.com>
Subject: Re: [PATCH] serial: 8250_lpss: Fix memory leak in lpss8250_probe()
In-Reply-To: <20240426114716.1275085-1-lumingyindetect@126.com>
Message-ID: <c6df7432-a76a-54e3-32f8-a94e9a18a3a3@linux.intel.com>
References: <20240426114716.1275085-1-lumingyindetect@126.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 26 Apr 2024, lumingyindetect@126.com wrote:

Hi,

Your patch should have had now (the version is missing):

Subject: [PATCH v3] serial: 8250_lpss: Fix memory leak in lpss8250_probe()

> From: LuMingYin <11570291+yin-luming@user.noreply.gitee.com>
> 
> In the execution logic of the lpss8250_probe() function, the function may directly return via a return statement at either line 347 or line 351.

Don't refer to line numbers and state too obvious things, effectively cut 
the "via a return statement at either ..." part out.

Like I already mentioned, there should be newline characters so that you 
don't exceed 75 characters.

> Unlike lines 357 or 361, where the return statement is used directly without releasing the dynamically allocated memory region pointed to by the variable pdev, causing a memory leak of the variable pdev.

Perhaps add part of this into the previous sentence (and again leave the 
talk about line numbers and return statement out of it, we all know that 
returning is done via return statement so it's uninteresting detail):

"... may directly return without releasing ..."

> In the lpss8250_probe() function, I added a label named "free_irq_vectors" to release the dynamically allocated memory region pointed to by the variable pdev, and replaced the two return statements mentioned above with goto statements to this label.

This is quite verbose way to state what can be read from the patch itself. 
Perhaps something like this can be used as replacement:

"Fix the issue by rolling back irq vector allocation."

> Fixes: e88c4cfcb7b888ac374916806f86c17d8ecaeb67

This gives you some examples:

git log | grep 'Fixes:'

Further information also available under Documentation/process/.

> 

Don't leave empty line here between Fixes and S-o-b tags.

> Signed-off-by: LuMingYin <11570291+yin-luming@user.noreply.gitee.com>
> ---

And here you should have listed changes you've made for each version (see 
ML archives for examples):

v3:
- ...

v2:
- ...

>  drivers/tty/serial/8250/8250_lpss.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_lpss.c b/drivers/tty/serial/8250/8250_lpss.c
> index c3cd6cb9ac80..fa9fd4dc86c7 100644
> --- a/drivers/tty/serial/8250/8250_lpss.c
> +++ b/drivers/tty/serial/8250/8250_lpss.c
> @@ -344,11 +344,11 @@ static int lpss8250_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  	uart.port.mapbase = pci_resource_start(pdev, 0);
>  	uart.port.membase = pcim_iomap(pdev, 0, 0);
>  	if (!uart.port.membase)
> -		return -ENOMEM;
> +		goto free_irq_vectors;
>  
>  	ret = lpss->board->setup(lpss, &uart.port);
>  	if (ret)
> -		return ret;
> +		goto free_irq_vectors;
>  
>  	dw8250_setup_port(&uart.port);
>  
> @@ -367,6 +367,7 @@ static int lpss8250_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  
>  err_exit:
>  	lpss->board->exit(lpss);
> +free_irq_vectors:
>  	pci_free_irq_vectors(pdev);
>  	return ret;
>  }
> 

-- 
 i.