Message-ID:
 <PAXPR04MB845923F8485ABF7DAEA390CB8891A@PAXPR04MB8459.eurprd04.prod.outlook.com>
Date: Wed, 28 Jan 2026 03:22:03 +0000
From: Peng Fan <peng.fan@....com>
To: Mathieu Poirier <mathieu.poirier@...aro.org>, Daniel Baluta
	<daniel.baluta@....com>, Iuliana Prodan <iuliana.prodan@....com>
CC: Bjorn Andersson <andersson@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>, Pengutronix Kernel Team
	<kernel@...gutronix.de>, Fabio Estevam <festevam@...il.com>, Iuliana Prodan
	<iuliana.prodan@....com>, Daniel Baluta <daniel.baluta@....com>, Frank Li
	<frank.li@....com>, "linux-remoteproc@...r.kernel.org"
	<linux-remoteproc@...r.kernel.org>, "imx@...ts.linux.dev"
	<imx@...ts.linux.dev>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "stable@...r.kernel.org"
	<stable@...r.kernel.org>
Subject: RE: [PATCH v2] remoteproc: imx_rproc: Not report loaded resource
 table when none

> Subject: Re: [PATCH v2] remoteproc: imx_rproc: Not report loaded
> resource table when none
> 
> On Mon, 26 Jan 2026 at 23:51, Peng Fan (OSS)
> <peng.fan@....nxp.com> wrote:
> >
> > From: Peng Fan <peng.fan@....com>
> >
> > priv->rsc_table is not NULL if the DT has a "rsc-table" entry,
> > priv->indicating
> > that _if_ there is a resource table in memory, that's where it should
> be.
> > Function imx_rproc_elf_find_loaded_rsc_table() is buggy so the
> > narrative about a previously running FW with a valid resource table
> can be dropped.
> >
> 
> (sigh)
> 
> You apparently did not understand my last comment.

Sorry about this. Does this looks good?

Daniel, Iuliana, would you please help review?

remoteproc: imx: Fix invalid loaded resource table detection

imx_rproc_elf_find_loaded_rsc_table() may incorrectly report a loaded
resource table even when the current firmware does not provide one.

When the device tree contains a "rsc-table" entry, priv->rsc_table is
non-NULL and denotes where a resource table would be located if one is
present in memory. However, when the current firmware has no resource table,
rproc->table_ptr is NULL. The function still returns priv->rsc_table, and the
remoteproc core interprets this as a valid loaded resource table.
.
Fix this by returning NULL from imx_rproc_elf_find_loaded_rsc_table() when
there is no resource table for the current firmware (i.e. when
rproc->table_ptr is NULL). This aligns the function's semantics with the
remoteproc core: a loaded resource table is only reported when a valid
table_ptr exists.

With this change, starting firmware without a resource table no longer
triggers a crash.

Thanks,
Peng.

> 
> > In this case rproc->table_ptr is NULL because the current firmware
> > does not contain a resource table, but the remoteproc core still
> > interprets the non-NULL return value as a loaded resource table and
> > attempts to memcpy() from rproc->cached_table, leading to a NULL
> > pointer dereference and kernel panic.
> >
> > Fix this by returning NULL from imx_rproc_elf_find_loaded_rsc_table()
> > when there is no cached resource table for the current firmware. This
> > ensures that a loaded resource table is only reported when a valid
> > table_ptr exists, which matches the remoteproc core expectations.
> >
> > This issue can be reproduced by:
> >   1) start a firmware with a resource table
> >   2) stop the remote processor
> >   3) start a firmware without a resource table
> >
> 
> Another sign you did not understand my last comment.
> 
> I had hopes of merging this patch but the changelog is too garbled to
> be salvageable.  I suggest you ask Daniel or Iuliana for help.
> 
> > With this change, starting a firmware without a resource table no
> > longer causes kernel dump.
> >
> > Fixes: e954a1bd1610 ("remoteproc: imx_rproc: Use imx specific hook
> for
> > find_loaded_rsc_table")
> > Cc: stable@...r.kernel.org
> > Signed-off-by: Peng Fan <peng.fan@....com>
> > ---
> > Changes in v2:
> > - Per Mathieu, Check rproc->table_ptr, update commit log
> > - Include R-b from Frank
> > - Link to v1:
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> lore
> > .kernel.org%2Fr%2F20260122-imx-rproc-fix-v1-1-
> 36cc64369a40%40nxp.com&d
> >
> ata=05%7C02%7Cpeng.fan%40nxp.com%7C781fb4227e024211e71c08
> de5dbb609e%7C
> >
> 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C639051256532
> 530786%7CUnknow
> >
> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw
> MCIsIlAiOiJXaW
> >
> 4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0
> 3sG8la72ysD
> > ivP9SMmA9Ry2YaiMvCjsHWAWaGFOVQw%3D&reserved=0
> > ---
> >  drivers/remoteproc/imx_rproc.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/remoteproc/imx_rproc.c
> > b/drivers/remoteproc/imx_rproc.c index
> >
> 375de79168a1c8d11b87ac1bd63774a3feac106d..f5f916d679051936
> 0f446f063e09
> > d018c5654953 100644
> > --- a/drivers/remoteproc/imx_rproc.c
> > +++ b/drivers/remoteproc/imx_rproc.c
> > @@ -729,6 +729,10 @@ imx_rproc_elf_find_loaded_rsc_table(struct
> rproc
> > *rproc, const struct firmware *  {
> >         struct imx_rproc *priv = rproc->priv;
> >
> > +       /* No resource table in the firmware */
> > +       if (!rproc->table_ptr)
> > +               return NULL;
> > +
> >         if (priv->rsc_table)
> >                 return (struct resource_table *)priv->rsc_table;
> >
> >
> > ---
> > base-commit: e3b32dcb9f23e3c3927ef3eec6a5842a988fb574
> > change-id: 20260122-imx-rproc-fix-e206f8e6e477
> >
> > Best regards,
> > --
> > Peng Fan <peng.fan@....com>
> >

Powered by blists - more mailing lists