Re: [PATCH v3 2/4] remoteproc: imx_rpoc: fix carveout name parsing

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] If `rproc_mem_entry_init()` fails, `imx_rproc_prepare()` returns an error without cleaning up carveouts and coredump segments added in previous loop iterations.
--

--- Patch [2]: [PATCH v3 2/4] remoteproc: imx_rpoc: fix carveout name parsing ---
commit 919463e3c08e2a14917d823b86fa8559b43af4fc
Author: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>

remoteproc: imx_rpoc: fix carveout name parsing

The imx remoteproc driver is updated to use the "memory-region-names" 
property for reserved memory regions instead of relying on devicetree 
node names. This allows standardizing node names according to the 
devicetree specification.

> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 7662ebd9d2f49..74719066905d6 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -672,7 +672,7 @@ static int imx_rproc_prepare(struct rproc *rproc)
>  		int err;
>  		struct resource res;
>  
> -		err = of_reserved_mem_region_to_resource(np, i++, &res);
> +		err = imx_rproc_rmem_to_resource(np, i++, &res);
>  		if (err)
>  			break;

[Severity: High]
This isn't a bug introduced by this patch, but looking at the loop in
imx_rproc_prepare(), does the early return on rproc_mem_entry_init() failure
leak resources?

If rproc_mem_entry_init() fails, it returns -ENOMEM without cleaning up 
the carveouts and coredump segments added in previous loop iterations:

drivers/remoteproc/imx_rproc.c:imx_rproc_prepare() {
	while (1) {
		...
		mem = rproc_mem_entry_init(...);
		if (!mem)
			return -ENOMEM;
		
		rproc_coredump_add_segment(rproc, da, resource_size(&res));
		rproc_add_carveout(rproc, mem);
	}
}

This error propagates back to rproc_fw_boot(), where the error handling path
skips the clean_up_resources: label and jumps straight to disable_iommu:.

If a boot is retried by userspace (e.g., via sysfs), could this continually
append duplicate entries to the lists and eventually exhaust vmalloc space
when rproc_alloc_registered_carveouts() iterates over the duplicates and
maps the same physical memory addresses multiple times?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730163412.1145-1-laurentiumihalcea111@gmail.com?part=2