From: LuMingYin <[email protected]>
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 <[email protected]>
---
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
…
> 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 <[email protected]>
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
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" <[email protected]> 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 <[email protected]>
>
>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
On Fri, 26 Apr 2024, [email protected] 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 <[email protected]>
>
> 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 <[email protected]>
> ---
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.
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, [email protected] wrote:
> From: LuMingYin <[email protected]>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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 <[email protected]>
> ---
> 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;
> }
> 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.
Would you like to take available information from published information sources
better into account?
Please take another look also at advices from the section “Describe your changes”.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.9-rc5#n145
By the way:
Did you try the development tool “scripts/checkpatch.pl” out for your change approach?
Regards,
Markus
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
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 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
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