From: sashiko-bot@kernel.org
To: "Ben Levinsky" <ben.levinsky@amd.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH 1/6] remoteproc: amd_mbv_bram: Bound device name formatting
Date: Wed, 14 Oct 2026 21:48:27 +0000 [thread overview]
Message-ID: <sashiko-outbox-171938@kernel.org> (raw)
In-Reply-To: <20261014213426.2957480-2-ben.levinsky@amd.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] remoteproc: carveout memory leak on rproc_parse_fw() failure
--
commit bb5382f10341b400baaa921ca1112dc728aa259e
Author: Ben Levinsky <ben.levinsky@amd.com>
remoteproc: amd_mbv_bram: Bound device name formatting
Pass the device name through a constant format string to prevent percent
conversions in the device name from consuming nonexistent variadic arguments,
and bound it to 31 characters.
> diff --git a/drivers/remoteproc/amd_mbv_bram_rproc.c b/drivers/remoteproc/amd_mbv_bram_rproc.c
> index e4a103cf84558..6cf33c7b7e641 100644
> --- a/drivers/remoteproc/amd_mbv_bram_rproc.c
> +++ b/drivers/remoteproc/amd_mbv_bram_rproc.c
> @@ -72,7 +72,7 @@ static int amd_bram_rproc_prepare(struct rproc *rproc)
> resource_size(&res), da,
> rproc_mem_entry_ioremap_wc,
> rproc_mem_entry_iounmap,
> - dev_name(priv->dev));
> + "%.31s", dev_name(priv->dev));
> if (!mem)
> return -ENOMEM;
>
[Severity: Medium]
Could this introduce a regression where the carveout memory leaks?
If rproc_parse_fw() fails during boot (for instance, due to a memory
allocation failure in rproc_elf_load_rsc_table()), the error path in
rproc_fw_boot() bypasses rproc_resource_cleanup():
drivers/remoteproc/remoteproc_core.c:rproc_fw_boot() {
...
ret = rproc_parse_fw(rproc, fw);
if (ret)
goto unprepare_rproc;
...
clean_up_resources:
rproc_resource_cleanup(rproc);
...
unprepare_rproc:
rproc_unprepare_device(rproc);
...
}
Because the driver adds the carveout to rproc->carveouts shortly after this
allocation:
mem = rproc_mem_entry_init(...);
if (!mem)
return -ENOMEM;
rproc_add_carveout(rproc, mem);
And relies on the core's rproc_resource_cleanup() for cleanup, the carveout
would remain on the list if parsing fails.
Subsequent rproc_boot() attempts would then call prepare() again, potentially
adding duplicate carveouts and causing unbounded list growth.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261014213426.2957480-1-ben.levinsky@amd.com?part=1
next prev parent reply other threads:[~2026-10-14 21:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 21:34 [PATCH 0/6] Add AMD PL Mailbox and RPMsg support for the AMD BRAM remoteproc Ben Levinsky
2026-10-14 21:34 ` [PATCH 1/6] remoteproc: amd_mbv_bram: Bound device name formatting Ben Levinsky
2026-10-14 21:48 ` sashiko-bot [this message]
2026-10-14 21:34 ` [PATCH 2/6] remoteproc: amd_mbv_bram: Restore reset GPIO direction after PL reconfig Ben Levinsky
2026-10-14 21:44 ` sashiko-bot
2026-10-14 21:34 ` [PATCH 3/6] dt-bindings: mailbox: Add AMD PL Mailbox IP Ben Levinsky
2026-10-14 21:34 ` [PATCH 4/6] mailbox: Add AMD PL Mailbox soft IP controller Ben Levinsky
2026-10-14 21:41 ` sashiko-bot
2026-10-14 21:34 ` [PATCH 5/6] dt-bindings: remoteproc: Add RPMsg resources to AMD BRAM rproc Ben Levinsky
2026-10-14 21:34 ` [PATCH 6/6] remoteproc: amd_mbv_bram: Add RPMsg support Ben Levinsky
2026-10-14 21:45 ` sashiko-bot
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=sashiko-outbox-171938@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=ben.levinsky@amd.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.