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.
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.
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.

Fixes: e88c4cfcb7b888ac374916806f86c17d8ecaeb67

Signed-off-by: LuMingYin <11570291+yin-luming@user.noreply.gitee.com>
---
 drivers/tty/serial/8250/8250_lpss.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

…
> 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.

* Please improve the word wrapping according to line length preferences
  for change descriptions.

* Please choose corresponding imperative wordings.


> Fixes: e88c4cfcb7b888ac374916806f86c17d8ecaeb67

Please add a commit subject for this tag.


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

I find the author email addresses suspicious according to the Developer's Certificate of Origin.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.9-rc5#n398

Would other email addresses be more appropriate for desired patch communication?

Regards,
Markus

Run scripts/checkpatch.pl --strict on your patch.

WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#15: 
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.
WARNING: Please use correct Fixes: style 'Fixes: <12 chars of sha1> ("<title line>")' - ie: 'Fixes: 12dadc409c2b ("Linux 6.8.7")'
#19: 
Fixes: e88c4cfcb7b888ac374916806f86c17d8ecaeb67

On Fri, Apr 26, 2024 at 12:47:16PM +0100, lumingyindetect@126.com wrote:
> From: LuMingYin <11570291+yin-luming@user.noreply.gitee.com>
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Fix this email address.

> 
> 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.

The line numbers are not important and they change all the time.
Instead say "if pcim_iomap() or lpss->board->setup() fail then ...".

> 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.
> 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.

Just say "Use a goto to release this memory".  No need to explain
further.

> 
> Fixes: e88c4cfcb7b888ac374916806f86c17d8ecaeb67

This is the wrong hash and the format is wrong.  It should be:

Fixes: 254cc7743e84 ("serial: 8250_lpss: Switch over to MSI interrupts")

> 
> Signed-off-by: LuMingYin <11570291+yin-luming@user.noreply.gitee.com>
> ---
>  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;

This needs to be:

	if (!uart.port.membase) {
		ret = -ENOMEM;
		goto free_irq_vectors;
	}

regards,
dan carpenter

>  
>  	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;
>  }

On 24/04/26 09:01PM, lumingyindetect wrote:
> Dear Markus,
>
> Thank you for your patient guidance and advice! This is my first time submitting a patch, and I haven't fully understood the meaning of "add a commit subject for this tag" yet. Could you please provide some examples or guidance on how to add it? I appreciate your help!
>
> Best regards,
> LuMingYin

Hey LuMingYin,

just for your information that while he means well the advice from
Markus is not always shared by other maintainers and their inablility to
adapt to such feedback got them banned for a while on lkml. See i.e.
https://lore.kernel.org/all/2024042547-shimmy-guileless-c7f2@gregkh/
for an instance where greg is sending a relevant reply to one of their
requested changes / feedback to patches.

So just evaluate for yourself whether the feedback makes sense and just
go along of the official documentation[0] and feedback you get from the
relevant subsystem maintainers.

Cheers,
chris

[0]: https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html

On Fri, Apr 26, 2024 at 06:32:33PM +0300, Dan Carpenter wrote:
> On Fri, Apr 26, 2024 at 05:45:49PM +0300, Andy Shevchenko wrote:
> > On Fri, Apr 26, 2024 at 04:53:18PM +0300, Dan Carpenter wrote:
> > 
> > > > Fixes: e88c4cfcb7b888ac374916806f86c17d8ecaeb67
> > > 
> > > This is the wrong hash and the format is wrong.  It should be:
> > > 
> > > Fixes: 254cc7743e84 ("serial: 8250_lpss: Switch over to MSI interrupts")
> > 
> > Since you are here, just pay attention that this does NOT fix anything
> > as it uses pcim_enable_device(). I hope smatch won't stumble over this
> > and produce false positives.
> > 
> 
> Ah...  No, this isn't a Smatch warning.  I think I tried to add it but
> was told it was wrong because I have this in my unpublished code.  :P
> 
> // Are these affected by pcim_enable_device()?
> //      { "pci_alloc_irq_vectors", ALLOC, 0, "$",  &int_one, &int_max },
> //      { "pci_free_irq_vectors", RELEASE, 0, "$" },
> 
> So when we're using pcim_enable_device(), calling pci_free_irq_vectors()
> is harmless but not necessary?

Yes, precisely.