From: Hongling Zeng <zhongling0719@126.com>
To: "Dominik Karol Piątkowski"
<dominik.karol.piatkowski@protonmail.com>,
"Hongling Zeng" <zenghongling@kylinos.cn>
Cc: dpenkler@gmail.com, gregkh@linuxfoundation.org, kees@kernel.org,
dan.carpenter@linaro.org, lukeyang.dev@gmail.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] gpib: fmh_gpib: Fix resource leaks in fmh_gpib_attach_impl
Date: Thu, 28 May 2026 09:20:07 +0800 [thread overview]
Message-ID: <6A179847.6000107@126.com> (raw)
In-Reply-To: <k7I9GeHLtRB0rzVLecazfQYmeqbWDN5bso07-1oSGmivcA0IiBDr8pbFVjAbY3n_g-kIoxjDP4lbJVqMvsxK_lkweJfIB9lij1nxGAwn21E=@protonmail.com>
Hi Dominik,
Thank you for the review. You're right on all three points:
在 2026年05月27日 21:14, Dominik Karol Piątkowski 写道:
> Hi Hongling Zeng,
>
> On Wednesday, May 27th, 2026 at 11:55, Hongling Zeng <zenghongling@kylinos.cn> wrote:
>
>> The fmh_gpib_attach_impl() function has multiple resource leaks in its
>> error handling paths. When any initialization step fails, the function
>> returns early without properly releasing previously acquired resources.
>>
>> Fix by adding proper error handling labels and cleanup code that releases
>> resources in the reverse order they were acquired.
>>
>> Fixes: 8e4841a0888c7 ("staging: gpib: Add Frank Mori Hess FPGA PCI GPIB driver")
>> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
>> ---
>> drivers/gpib/fmh_gpib/fmh_gpib.c | 46 ++++++++++++++++++++++++--------
>> 1 file changed, 35 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpib/fmh_gpib/fmh_gpib.c b/drivers/gpib/fmh_gpib/fmh_gpib.c
>> index fcafdc02ea2e..af582453fef7 100644
>> --- a/drivers/gpib/fmh_gpib/fmh_gpib.c
>> +++ b/drivers/gpib/fmh_gpib/fmh_gpib.c
>> @@ -1403,14 +1403,17 @@ static int fmh_gpib_attach_impl(struct gpib_board *board, const struct gpib_boar
>> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "gpib_control_status");
>> if (!res) {
>> dev_err(board->dev, "Unable to locate mmio resource\n");
>> - return -ENODEV;
>> + retval = -ENODEV;
>> + return retval;
> Replacing `return -errno` with `retval = -errno` just to have `return retval`
> directly under it does not convince me.
Early error returns can just use return -ENODEV directly
>> }
>>
>> if (request_mem_region(res->start,
>> resource_size(res),
>> pdev->name) == NULL) {
>> dev_err(board->dev, "cannot claim registers\n");
>> - return -ENXIO;
>> + retval = -ENXIO;
>> + return retval;
>> +
> Same here, also introducing unnecessary newline.
Will remove the extra newline
>
>> }
>> e_priv->gpib_iomem_res = res;
>>
>> @@ -1418,7 +1421,8 @@ static int fmh_gpib_attach_impl(struct gpib_board *board, const struct gpib_boar
>> resource_size(e_priv->gpib_iomem_res));
>> if (!nec_priv->mmiobase) {
>> dev_err(board->dev, "Could not map I/O memory\n");
>> - return -ENOMEM;
>> + retval = -ENOMEM;
>> + goto err_release_gpib_region;
>> }
>> dev_dbg(board->dev, "iobase %pr remapped to %p\n",
>> e_priv->gpib_iomem_res, nec_priv->mmiobase);
>> @@ -1426,42 +1430,48 @@ static int fmh_gpib_attach_impl(struct gpib_board *board, const struct gpib_boar
>> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dma_fifos");
>> if (!res) {
>> dev_err(board->dev, "Unable to locate mmio resource for gpib dma port\n");
>> - return -ENODEV;
>> + retval = -ENODEV;
>> + goto err_iounmap_gpib;
>> }
>> if (request_mem_region(res->start,
>> resource_size(res),
>> pdev->name) == NULL) {
>> dev_err(board->dev, "cannot claim registers\n");
>> - return -ENXIO;
>> + retval = -ENXIO;
>> + goto err_iounmap_gpib;
>> }
>> e_priv->dma_port_res = res;
>> e_priv->fifo_base = ioremap(e_priv->dma_port_res->start,
>> resource_size(e_priv->dma_port_res));
>> if (!e_priv->fifo_base) {
>> dev_err(board->dev, "Could not map I/O memory for fifos\n");
>> - return -ENOMEM;
>> + retval = -ENOMEM;
>> + goto err_release_dma_region;
>> }
>> dev_dbg(board->dev, "dma fifos 0x%lx remapped to %p, length=%ld\n",
>> (unsigned long)e_priv->dma_port_res->start, e_priv->fifo_base,
>> (unsigned long)resource_size(e_priv->dma_port_res));
>>
>> irq = platform_get_irq(pdev, 0);
>> - if (irq < 0)
>> - return -EBUSY;
>> + if (irq < 0) {
>> + retval = -EBUSY;
>> + goto err_iounmap_fifo;
>> + }
>> + e_priv->irq = irq;
> I don't think this assignment should be moved before request_irq.
>
> Thanks,
> Dominik Karol
e_priv->irq = irq; should stay after request_irq() succeeds - my concern
about uninitialized values in error paths was incorrect since
err_iounmap_fifo doesn't use e_priv->irq
I'll fix these issues and resubmit.
Best regards,
Hongling Zeng
>> retval = request_irq(irq, fmh_gpib_interrupt, IRQF_SHARED, pdev->name, board);
>> if (retval) {
>> dev_err(board->dev,
>> "cannot register interrupt handler err=%d\n",
>> retval);
>> - return retval;
>> + goto err_iounmap_fifo;
>> }
>> - e_priv->irq = irq;
>>
>> if (acquire_dma) {
>> e_priv->dma_channel = dma_request_slave_channel(board->dev, "rxtx");
>> if (!e_priv->dma_channel) {
>> dev_err(board->dev, "failed to acquire dma channel \"rxtx\".\n");
>> - return -EIO;
>> + retval = -EIO;
>> + goto err_free_irq;
>> }
>> }
>> /*
>> @@ -1473,6 +1483,20 @@ static int fmh_gpib_attach_impl(struct gpib_board *board, const struct gpib_boar
>> fifo_max_burst_length_mask;
>>
>> return fmh_gpib_init(e_priv, board, handshake_mode);
>> +
>> +err_free_irq:
>> + free_irq(e_priv->irq, board);
>> +err_iounmap_fifo:
>> + iounmap(e_priv->fifo_base);
>> +err_release_dma_region:
>> + release_mem_region(e_priv->dma_port_res->start,
>> + resource_size(e_priv->dma_port_res));
>> +err_iounmap_gpib:
>> + iounmap(nec_priv->mmiobase);
>> +err_release_gpib_region:
>> + release_mem_region(e_priv->gpib_iomem_res->start,
>> + resource_size(e_priv->gpib_iomem_res));
>> + return retval;
>> }
>>
>> int fmh_gpib_attach_holdoff_all(struct gpib_board *board, const struct gpib_board_config *config)
>> --
>> 2.25.1
>>
>>
prev parent reply other threads:[~2026-05-28 1:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-27 9:54 [PATCH] gpib: fmh_gpib: Fix resource leaks in fmh_gpib_attach_impl Hongling Zeng
2026-05-27 11:21 ` Greg KH
2026-05-27 13:14 ` Dominik Karol Piątkowski
2026-05-28 1:20 ` Hongling Zeng [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6A179847.6000107@126.com \
--to=zhongling0719@126.com \
--cc=dan.carpenter@linaro.org \
--cc=dominik.karol.piatkowski@protonmail.com \
--cc=dpenkler@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukeyang.dev@gmail.com \
--cc=zenghongling@kylinos.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.