From: Peng Fan <[email protected]>
Per elf specification,
p_filesz: This member gives the number of bytes in the file image of
the segment; it may be zero.
p_memsz: This member gives the number of bytes in the memory image
of the segment; it may be zero.
There is a case that i.MX DSP firmware has segment with PT_LOAD and
p_memsz/p_filesz set to zero. Such segment needs to be ignored,
otherwize rproc_da_to_va would report error.
Signed-off-by: Peng Fan <[email protected]>
---
drivers/remoteproc/remoteproc_elf_loader.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/remoteproc_elf_loader.c b/drivers/remoteproc/remoteproc_elf_loader.c
index d635d19a5aa8..cb77f9e4dc70 100644
--- a/drivers/remoteproc/remoteproc_elf_loader.c
+++ b/drivers/remoteproc/remoteproc_elf_loader.c
@@ -181,7 +181,14 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
bool is_iomem = false;
void *ptr;
- if (type != PT_LOAD)
+ /*
+ * There is a case that with PT_LOAD type, the
+ * filesz = memsz = 0. If memsz = 0, rproc_da_to_va
+ * should return NULL ptr, then error is returned.
+ * So this case should be skipped from the loop.
+ * Add !memsz checking here.
+ */
+ if (type != PT_LOAD || !memsz)
continue;
dev_dbg(dev, "phdr: type %d da 0x%llx memsz 0x%llx filesz 0x%llx\n",
--
2.25.1
Hi Peng,
On Wed, Mar 23, 2022 at 02:49:43PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <[email protected]>
>
> Per elf specification,
> p_filesz: This member gives the number of bytes in the file image of
> the segment; it may be zero.
> p_memsz: This member gives the number of bytes in the memory image
> of the segment; it may be zero.
>
> There is a case that i.MX DSP firmware has segment with PT_LOAD and
> p_memsz/p_filesz set to zero. Such segment needs to be ignored,
> otherwize rproc_da_to_va would report error.
>
> Signed-off-by: Peng Fan <[email protected]>
> ---
> drivers/remoteproc/remoteproc_elf_loader.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/remoteproc_elf_loader.c b/drivers/remoteproc/remoteproc_elf_loader.c
> index d635d19a5aa8..cb77f9e4dc70 100644
> --- a/drivers/remoteproc/remoteproc_elf_loader.c
> +++ b/drivers/remoteproc/remoteproc_elf_loader.c
> @@ -181,7 +181,14 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
> bool is_iomem = false;
> void *ptr;
>
> - if (type != PT_LOAD)
> + /*
> + * There is a case that with PT_LOAD type, the
> + * filesz = memsz = 0. If memsz = 0, rproc_da_to_va
> + * should return NULL ptr, then error is returned.
> + * So this case should be skipped from the loop.
> + * Add !memsz checking here.
There are several architecture where XYZ_da_to_va() does not return a NULL
pointer when @len is 0, making this comment inaccurate. Please remove that
part.
> + */
> + if (type != PT_LOAD || !memsz)
> continue;
I have reflected long and hard on this one...
If @memsz is 0 then @filesz _has_ to be 0, otherwise rproc_elf_load_segments()
returns -EINVAL. If @filesz is also 0 then nothing gets copied (for
architectures where XYZ_da_to_va() doesn't return a NULL pointer when @len is
0), which is exactly the same as what the above change does.
As such I am inclined to view this set favourably. That being said we will
have to proceed cautiously. If something breaks we will have to revert it.
Please send another revision as quickly as possible so that it can stay in
linux-next long enough to, hopefully, catch any problems.
With the above and for this set:
Reviewed-by: Mathieu Poirier <[email protected]>
>
> dev_dbg(dev, "phdr: type %d da 0x%llx memsz 0x%llx filesz 0x%llx\n",
> --
> 2.25.1
>