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

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

[lumingyindetect]

From: LuMingYin <lumingyindetect@126.com>

The return statements at line 347 and line 351 in the lpss8250_probe() function result in a memory leak of the variable pdev.
Add a label named free_irq_vectors in the lpss8250_probe() function to release the memory area pointed to by pdev.
Modify the two return statements mentioned above to jump to the label "free_irq_vectors" instead.

Fixes: e88c4cfcb7b888ac374916806f86c17d8ecaeb67 ("serial: 8250_lpss: fix memory in lpss8250_probe()")

Signed-off-by: LuMingYin <lumingyindetect@126.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;
 
 	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;
 }
-- 
2.25.1

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

[Ilpo Järvinen]

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

> From: LuMingYin <lumingyindetect@126.com>
> 
> The return statements at line 347 and line 351 in the lpss8250_probe() function result in a memory leak of the variable pdev.
> Add a label named free_irq_vectors in the lpss8250_probe() function to release the memory area pointed to by pdev.
> Modify the two return statements mentioned above to jump to the label "free_irq_vectors" instead.

Also, this is not a 100m sprint. Please leave time for people to comment 
on your previous submission before sending the next version out.

People are from different timezones and have other things to look too 
besides your patch so they might not be happy if they find 4 versions of 
your patch in their inbox before even having time to look at the first 
one.

-- 
 i.

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

[Greg KH]

On Fri, Apr 26, 2024 at 02:39:59PM +0100, lumingyindetect@126.com wrote:
> From: LuMingYin <lumingyindetect@126.com>
> 
> The return statements at line 347 and line 351 in the lpss8250_probe() function result in a memory leak of the variable pdev.
> Add a label named free_irq_vectors in the lpss8250_probe() function to release the memory area pointed to by pdev.
> Modify the two return statements mentioned above to jump to the label "free_irq_vectors" instead.
> 
> Fixes: e88c4cfcb7b888ac374916806f86c17d8ecaeb67 ("serial: 8250_lpss: fix memory in lpss8250_probe()")
> 
> Signed-off-by: LuMingYin <lumingyindetect@126.com>

Please stop and read all of the instructions provide, and then go read
the "how to submit your first patch" tutorial at kernelnewbies.org and
compare that to what you have been sending here.

You also keep sending stuff to quickly, patches should be, at the most,
sent once a day, and even then, that would be very quick.

Relax, take the weekend off, and come back next week with a proper
change based on the documentation.

thanks,

greg k-h

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

[Andy Shevchenko]

On Fri, Apr 26, 2024 at 02:39:59PM +0100, lumingyindetect@126.com wrote:
> From: LuMingYin <lumingyindetect@126.com>
> 
> The return statements at line 347 and line 351 in the lpss8250_probe()
> function result in a memory leak of the variable pdev.  Add a label named
> free_irq_vectors in the lpss8250_probe() function to release the memory area
> pointed to by pdev.  Modify the two return statements mentioned above to jump
> to the label "free_irq_vectors" instead.

> Fixes: e88c4cfcb7b888ac374916806f86c17d8ecaeb67 ("serial: 8250_lpss: fix memory in lpss8250_probe()")

Same as for the previous version, NAK.

This patch does NOT fix anything. Please, read the code and try to understand
how it works.

-- 
With Best Regards,
Andy Shevchenko

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

[lumingyindetect]

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(-)

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

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

[Markus Elfring]

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

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

[lumingyindetect]

Dear Markus,<br/><br/>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!<br/><br/>Best regards,<br/>LuMingYin
At 2024-04-26 20:28:43, "Markus Elfring" <Markus.Elfring@web.de> wrote:
>…
>> 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

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

[Christian Heusel]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ilpo Järvinen]

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.

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

[Dan Carpenter]

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

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

[Andy Shevchenko]

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.

-- 
With Best Regards,
Andy Shevchenko

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

[Dan Carpenter]

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?

regards,
dan carpenter

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

[Andy Shevchenko]

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.

-- 
With Best Regards,
Andy Shevchenko