* [PATCH v3] remoteproc: imx: Fix invalid loaded resource table detection
@ 2026-01-29 1:44 Peng Fan (OSS)
2026-01-29 16:02 ` Daniel Baluta
2026-02-03 16:28 ` Mathieu Poirier
0 siblings, 2 replies; 6+ messages in thread
From: Peng Fan (OSS) @ 2026-01-29 1:44 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Iuliana Prodan,
Daniel Baluta, Frank Li
Cc: linux-remoteproc, imx, linux-arm-kernel, linux-kernel, Peng Fan,
stable
From: Peng Fan <peng.fan@nxp.com>
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.
Fixes: e954a1bd1610 ("remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table")
Cc: stable@vger.kernel.org
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Changes in v3:
- Update patch subject and commit message using this one [1]
[1] https://lore.kernel.org/all/CANLsYkyrz+A1iEabGZ6rFybFo4=mM+TPVDRSckFB2YUS_7aKow@mail.gmail.com/
- Link to v2: https://lore.kernel.org/r/20260127-imx-rproc-fix-v2-1-7288fcf74385@nxp.com
Changes in v2:
- Per Mathieu, Check rproc->table_ptr, update commit log
- Include R-b from Frank
- Link to v1: https://lore.kernel.org/r/20260122-imx-rproc-fix-v1-1-36cc64369a40@nxp.com
---
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..f5f916d6790519360f446f063e09d018c5654953 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@nxp.com>
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH v3] remoteproc: imx: Fix invalid loaded resource table detection 2026-01-29 1:44 [PATCH v3] remoteproc: imx: Fix invalid loaded resource table detection Peng Fan (OSS) @ 2026-01-29 16:02 ` Daniel Baluta 2026-01-30 3:27 ` Peng Fan 2026-02-02 16:16 ` Mathieu Poirier 2026-02-03 16:28 ` Mathieu Poirier 1 sibling, 2 replies; 6+ messages in thread From: Daniel Baluta @ 2026-01-29 16:02 UTC (permalink / raw) To: Peng Fan (OSS) Cc: Bjorn Andersson, Mathieu Poirier, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Iuliana Prodan, Daniel Baluta, Frank Li, linux-remoteproc, imx, linux-arm-kernel, linux-kernel, Peng Fan, stable On Thu, Jan 29, 2026 at 3:45 AM Peng Fan (OSS) <peng.fan@oss.nxp.com> wrote: > > From: Peng Fan <peng.fan@nxp.com> > > 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. > > Fixes: e954a1bd1610 ("remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table") > Cc: stable@vger.kernel.org > Signed-off-by: Peng Fan <peng.fan@nxp.com> Changes looks good to me > > --- 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; I wonder if we can make this change generic because it should happen on other platforms also. Maybe something like this: remoteproc: core: Only copy loaded table when valid Copy resource table in memory only when: * the current loaded firmware provides one AND * there is an explicit request to have the rsc table copied in memory via rsc-table --- a/drivers/remoteproc/remoteproc_core.c +++ b/drivers/remoteproc/remoteproc_core.c @@ -1281,7 +1281,7 @@ static int rproc_start(struct rproc *rproc, const struct firmware *fw) * that any subsequent changes will be applied to the loaded version. */ loaded_table = rproc_find_loaded_rsc_table(rproc, fw); - if (loaded_table) { + if (rproc->cached_table && loaded_table) { memcpy(loaded_table, rproc->cached_table, rproc->table_sz); rproc->table_ptr = loaded_table; } ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3] remoteproc: imx: Fix invalid loaded resource table detection 2026-01-29 16:02 ` Daniel Baluta @ 2026-01-30 3:27 ` Peng Fan 2026-02-02 16:16 ` Mathieu Poirier 1 sibling, 0 replies; 6+ messages in thread From: Peng Fan @ 2026-01-30 3:27 UTC (permalink / raw) To: Daniel Baluta Cc: Bjorn Andersson, Mathieu Poirier, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Iuliana Prodan, Daniel Baluta, Frank Li, linux-remoteproc, imx, linux-arm-kernel, linux-kernel, Peng Fan, stable Hi Daniel, On Thu, Jan 29, 2026 at 06:02:21PM +0200, Daniel Baluta wrote: >On Thu, Jan 29, 2026 at 3:45 AM Peng Fan (OSS) <peng.fan@oss.nxp.com> wrote: >> >> From: Peng Fan <peng.fan@nxp.com> >> >> 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. >> >> Fixes: e954a1bd1610 ("remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table") >> Cc: stable@vger.kernel.org >> Signed-off-by: Peng Fan <peng.fan@nxp.com> > >Changes looks good to me > > >> --- 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; > >I wonder if we can make this change generic because it should happen >on other platforms also. > >Maybe something like this: > >remoteproc: core: Only copy loaded table when valid > >Copy resource table in memory only when: >* the current loaded firmware provides one >AND >* there is an explicit request to have the rsc table copied in memory >via rsc-table > >--- a/drivers/remoteproc/remoteproc_core.c >+++ b/drivers/remoteproc/remoteproc_core.c >@@ -1281,7 +1281,7 @@ static int rproc_start(struct rproc *rproc, >const struct firmware *fw) > * that any subsequent changes will be applied to the loaded version. > */ > loaded_table = rproc_find_loaded_rsc_table(rproc, fw); >- if (loaded_table) { >+ if (rproc->cached_table && loaded_table) { > memcpy(loaded_table, rproc->cached_table, rproc->table_sz); > rproc->table_ptr = loaded_table; > } This change looks fine to me; however, it should not be treated as a bug fix for imx_rproc. Since we need a proper Fixes tag for backporting, I would still prefer using the changes in my original patch to ensure it can be applied to older releases. As for the modification you introduced, I think it can serve as a guard to prevent potential issues on other platforms. You could submit it separately as a formal patch to the mailing list. Thanks, Peng ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3] remoteproc: imx: Fix invalid loaded resource table detection 2026-01-29 16:02 ` Daniel Baluta 2026-01-30 3:27 ` Peng Fan @ 2026-02-02 16:16 ` Mathieu Poirier 2026-02-03 7:53 ` Daniel Baluta 1 sibling, 1 reply; 6+ messages in thread From: Mathieu Poirier @ 2026-02-02 16:16 UTC (permalink / raw) To: Daniel Baluta Cc: Peng Fan (OSS), Bjorn Andersson, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Iuliana Prodan, Daniel Baluta, Frank Li, linux-remoteproc, imx, linux-arm-kernel, linux-kernel, Peng Fan, stable On Thu, Jan 29, 2026 at 06:02:21PM +0200, Daniel Baluta wrote: > On Thu, Jan 29, 2026 at 3:45 AM Peng Fan (OSS) <peng.fan@oss.nxp.com> wrote: > > > > From: Peng Fan <peng.fan@nxp.com> > > > > 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. > > > > Fixes: e954a1bd1610 ("remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table") > > Cc: stable@vger.kernel.org > > Signed-off-by: Peng Fan <peng.fan@nxp.com> > > Changes looks good to me > > > > --- 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; > > I wonder if we can make this change generic because it should happen > on other platforms also. > > Maybe something like this: > > remoteproc: core: Only copy loaded table when valid > > Copy resource table in memory only when: > * the current loaded firmware provides one > AND > * there is an explicit request to have the rsc table copied in memory > via rsc-table > > --- a/drivers/remoteproc/remoteproc_core.c > +++ b/drivers/remoteproc/remoteproc_core.c > @@ -1281,7 +1281,7 @@ static int rproc_start(struct rproc *rproc, > const struct firmware *fw) > * that any subsequent changes will be applied to the loaded version. > */ > loaded_table = rproc_find_loaded_rsc_table(rproc, fw); > - if (loaded_table) { > + if (rproc->cached_table && loaded_table) { But we would be doing the check for rproc->table_ptr twice (->table_ptr and ->cached_table should be the same). The way it is currently writting forces vendor specific implementation of rproc_elf_find_loaded_rsc_table() to do the right thing. The merge window has been pushed by a week, giving me an opportunity to merge this patch. Should I do that or should we continue discussing the best approach? > memcpy(loaded_table, rproc->cached_table, rproc->table_sz); > rproc->table_ptr = loaded_table; > } ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3] remoteproc: imx: Fix invalid loaded resource table detection 2026-02-02 16:16 ` Mathieu Poirier @ 2026-02-03 7:53 ` Daniel Baluta 0 siblings, 0 replies; 6+ messages in thread From: Daniel Baluta @ 2026-02-03 7:53 UTC (permalink / raw) To: Mathieu Poirier Cc: Peng Fan (OSS), Bjorn Andersson, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Iuliana Prodan, Daniel Baluta, Frank Li, linux-remoteproc, imx, linux-arm-kernel, linux-kernel, Peng Fan, stable On Mon, Feb 2, 2026 at 6:16 PM Mathieu Poirier <mathieu.poirier@linaro.org> wrote: > > On Thu, Jan 29, 2026 at 06:02:21PM +0200, Daniel Baluta wrote: > > On Thu, Jan 29, 2026 at 3:45 AM Peng Fan (OSS) <peng.fan@oss.nxp.com> wrote: > > > > > > From: Peng Fan <peng.fan@nxp.com> > > > > > > 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. > > > > > > Fixes: e954a1bd1610 ("remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table") > > > Cc: stable@vger.kernel.org > > > Signed-off-by: Peng Fan <peng.fan@nxp.com> > > > > Changes looks good to me > > > > > > --- 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; > > > > I wonder if we can make this change generic because it should happen > > on other platforms also. > > > > Maybe something like this: > > > > remoteproc: core: Only copy loaded table when valid > > > > Copy resource table in memory only when: > > * the current loaded firmware provides one > > AND > > * there is an explicit request to have the rsc table copied in memory > > via rsc-table > > > > --- a/drivers/remoteproc/remoteproc_core.c > > +++ b/drivers/remoteproc/remoteproc_core.c > > @@ -1281,7 +1281,7 @@ static int rproc_start(struct rproc *rproc, > > const struct firmware *fw) > > * that any subsequent changes will be applied to the loaded version. > > */ > > loaded_table = rproc_find_loaded_rsc_table(rproc, fw); > > - if (loaded_table) { > > + if (rproc->cached_table && loaded_table) { > > But we would be doing the check for rproc->table_ptr twice (->table_ptr and > ->cached_table should be the same). The way it is currently writting forces > vendor specific implementation of rproc_elf_find_loaded_rsc_table() to do the > right thing. > > The merge window has been pushed by a week, giving me an opportunity to merge > this patch. Should I do that or should we continue discussing the best > approach? Let's go with Peng's approach: Acked-by: Daniel Baluta <daniel.baluta@nxp.com> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3] remoteproc: imx: Fix invalid loaded resource table detection 2026-01-29 1:44 [PATCH v3] remoteproc: imx: Fix invalid loaded resource table detection Peng Fan (OSS) 2026-01-29 16:02 ` Daniel Baluta @ 2026-02-03 16:28 ` Mathieu Poirier 1 sibling, 0 replies; 6+ messages in thread From: Mathieu Poirier @ 2026-02-03 16:28 UTC (permalink / raw) To: Peng Fan (OSS) Cc: Bjorn Andersson, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Iuliana Prodan, Daniel Baluta, Frank Li, linux-remoteproc, imx, linux-arm-kernel, linux-kernel, Peng Fan, stable On Thu, Jan 29, 2026 at 09:44:48AM +0800, Peng Fan (OSS) wrote: > From: Peng Fan <peng.fan@nxp.com> > > 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. > > Fixes: e954a1bd1610 ("remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table") > Cc: stable@vger.kernel.org > Signed-off-by: Peng Fan <peng.fan@nxp.com> > --- > Changes in v3: > - Update patch subject and commit message using this one [1] > [1] https://lore.kernel.org/all/CANLsYkyrz+A1iEabGZ6rFybFo4=mM+TPVDRSckFB2YUS_7aKow@mail.gmail.com/ > - Link to v2: https://lore.kernel.org/r/20260127-imx-rproc-fix-v2-1-7288fcf74385@nxp.com > > Changes in v2: > - Per Mathieu, Check rproc->table_ptr, update commit log > - Include R-b from Frank > - Link to v1: https://lore.kernel.org/r/20260122-imx-rproc-fix-v1-1-36cc64369a40@nxp.com > --- > 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..f5f916d6790519360f446f063e09d018c5654953 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; > Applied. Thanks, Mathieu > > --- > base-commit: e3b32dcb9f23e3c3927ef3eec6a5842a988fb574 > change-id: 20260122-imx-rproc-fix-e206f8e6e477 > > Best regards, > -- > Peng Fan <peng.fan@nxp.com> > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-02-03 16:28 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-01-29 1:44 [PATCH v3] remoteproc: imx: Fix invalid loaded resource table detection Peng Fan (OSS) 2026-01-29 16:02 ` Daniel Baluta 2026-01-30 3:27 ` Peng Fan 2026-02-02 16:16 ` Mathieu Poirier 2026-02-03 7:53 ` Daniel Baluta 2026-02-03 16:28 ` Mathieu Poirier
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox