From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Peng Fan <peng.fan@nxp.com>
Cc: "ohad@wizery.com" <ohad@wizery.com>,
"linux-remoteproc@vger.kernel.org"
<linux-remoteproc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
dl-linux-imx <linux-imx@nxp.com>
Subject: Re: [PATCH 2/2] remoteproc: use filesz as backup when translate memsz fail
Date: Fri, 10 Apr 2020 18:55:25 -0700 [thread overview]
Message-ID: <20200411015522.GK576963@builder.lan> (raw)
In-Reply-To: <AM0PR04MB4481B8AA8ADB836ED8398ADF88DE0@AM0PR04MB4481.eurprd04.prod.outlook.com>
On Thu 09 Apr 18:32 PDT 2020, Peng Fan wrote:
> Hi Bjorn,
>
> > Subject: Re: [PATCH 2/2] remoteproc: use filesz as backup when translate
> > memsz fail
> >
> > On Thu 09 Apr 01:22 PDT 2020, Peng Fan wrote:
> >
> > > Since we no need memset if memsz is larger than filesz, we could use
> > > filesz for the da to va translation when memsz translation fail.
> > >
> >
> > To me this implies that the firmware has a segment that's larger than the
> > memory that it's going to run in. I think even if we're not writing to the entire
> > memsz, asking da_to_va for the entire memsz provides a valuable sanity
> > check.
>
> da_to_va implies that Linux should have the va map to da. However
> that will be case that Linux is not able to touch all da, it only able touch
> half. Then Linux should also map all da?
>
So you have memory described in your ELF that can only be accessed by
the remoteproc? And this memory is covered by segments of type PT_LOAD?
What's your strategy for making sure that filesz stays within the
boundaries that the ELF loader is allowed to touch?
Regards,
Bjorn
> Thanks,
> Peng.
>
> >
> > Regards,
> > Bjorn
> >
> > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > ---
> > > drivers/remoteproc/remoteproc_elf_loader.c | 12 ++++++++++--
> > > 1 file changed, 10 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/remoteproc/remoteproc_elf_loader.c
> > > b/drivers/remoteproc/remoteproc_elf_loader.c
> > > index cc50fe70d50c..74d425a4b34c 100644
> > > --- a/drivers/remoteproc/remoteproc_elf_loader.c
> > > +++ b/drivers/remoteproc/remoteproc_elf_loader.c
> > > @@ -229,8 +229,16 @@ int rproc_elf_load_segments(struct rproc *rproc,
> > const struct firmware *fw)
> > > if (!ptr) {
> > > dev_err(dev, "bad phdr da 0x%llx mem 0x%llx\n", da,
> > > memsz);
> > > - ret = -EINVAL;
> > > - break;
> > > +
> > > + ptr = rproc_da_to_va(rproc, da, filesz);
> > > + if (!ptr) {
> > > + dev_err(dev,
> > > + "bad phdr da 0x%llx mem 0x%llx\n",
> > > + da, filesz);
> > > + ret = -EINVAL;
> > > + break;
> > > + }
> > > +
> > > }
> > >
> > > /* put the segment where the remote processor expects it */
> > > --
> > > 2.16.4
> > >
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Peng Fan <peng.fan@nxp.com>
Cc: "ohad@wizery.com" <ohad@wizery.com>,
"linux-remoteproc@vger.kernel.org"
<linux-remoteproc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
dl-linux-imx <linux-imx@nxp.com>
Subject: Re: [PATCH 2/2] remoteproc: use filesz as backup when translate memsz fail
Date: Fri, 10 Apr 2020 18:55:22 -0700 [thread overview]
Message-ID: <20200411015522.GK576963@builder.lan> (raw)
Message-ID: <20200411015522.IO0PjAMyXhal0Qx4HfHS-wbI5vHrT_FdbqqltgAZ7l4@z> (raw)
In-Reply-To: <AM0PR04MB4481B8AA8ADB836ED8398ADF88DE0@AM0PR04MB4481.eurprd04.prod.outlook.com>
On Thu 09 Apr 18:32 PDT 2020, Peng Fan wrote:
> Hi Bjorn,
>
> > Subject: Re: [PATCH 2/2] remoteproc: use filesz as backup when translate
> > memsz fail
> >
> > On Thu 09 Apr 01:22 PDT 2020, Peng Fan wrote:
> >
> > > Since we no need memset if memsz is larger than filesz, we could use
> > > filesz for the da to va translation when memsz translation fail.
> > >
> >
> > To me this implies that the firmware has a segment that's larger than the
> > memory that it's going to run in. I think even if we're not writing to the entire
> > memsz, asking da_to_va for the entire memsz provides a valuable sanity
> > check.
>
> da_to_va implies that Linux should have the va map to da. However
> that will be case that Linux is not able to touch all da, it only able touch
> half. Then Linux should also map all da?
>
So you have memory described in your ELF that can only be accessed by
the remoteproc? And this memory is covered by segments of type PT_LOAD?
What's your strategy for making sure that filesz stays within the
boundaries that the ELF loader is allowed to touch?
Regards,
Bjorn
> Thanks,
> Peng.
>
> >
> > Regards,
> > Bjorn
> >
> > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > ---
> > > drivers/remoteproc/remoteproc_elf_loader.c | 12 ++++++++++--
> > > 1 file changed, 10 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/remoteproc/remoteproc_elf_loader.c
> > > b/drivers/remoteproc/remoteproc_elf_loader.c
> > > index cc50fe70d50c..74d425a4b34c 100644
> > > --- a/drivers/remoteproc/remoteproc_elf_loader.c
> > > +++ b/drivers/remoteproc/remoteproc_elf_loader.c
> > > @@ -229,8 +229,16 @@ int rproc_elf_load_segments(struct rproc *rproc,
> > const struct firmware *fw)
> > > if (!ptr) {
> > > dev_err(dev, "bad phdr da 0x%llx mem 0x%llx\n", da,
> > > memsz);
> > > - ret = -EINVAL;
> > > - break;
> > > +
> > > + ptr = rproc_da_to_va(rproc, da, filesz);
> > > + if (!ptr) {
> > > + dev_err(dev,
> > > + "bad phdr da 0x%llx mem 0x%llx\n",
> > > + da, filesz);
> > > + ret = -EINVAL;
> > > + break;
> > > + }
> > > +
> > > }
> > >
> > > /* put the segment where the remote processor expects it */
> > > --
> > > 2.16.4
> > >
next prev parent reply other threads:[~2020-04-11 1:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-09 8:22 [PATCH 1/2] remoteproc: drop memset when loading elf segments Peng Fan
2020-04-09 8:22 ` [PATCH 2/2] remoteproc: use filesz as backup when translate memsz fail Peng Fan
2020-04-10 1:22 ` Bjorn Andersson
2020-04-10 1:22 ` Bjorn Andersson
2020-04-10 1:22 ` Bjorn Andersson
2020-04-10 1:32 ` Peng Fan
2020-04-11 1:55 ` Bjorn Andersson [this message]
2020-04-11 1:55 ` Bjorn Andersson
2020-04-11 1:55 ` Bjorn Andersson
2020-04-17 19:21 ` Mathieu Poirier
2020-04-18 9:10 ` Peng Fan
2020-04-10 1:20 ` [PATCH 1/2] remoteproc: drop memset when loading elf segments Bjorn Andersson
2020-04-10 1:20 ` Bjorn Andersson
2020-04-10 1:20 ` Bjorn Andersson
2020-04-10 1:29 ` Peng Fan
2020-04-11 1:51 ` Bjorn Andersson
2020-04-11 1:51 ` Bjorn Andersson
2020-04-11 1:51 ` Bjorn Andersson
2020-04-13 9:05 ` Peng Fan
2020-04-17 16:43 ` Suman Anna
2020-04-21 7:42 ` Peng Fan
2020-04-21 18:25 ` Suman Anna
2020-05-11 9:15 ` Clément Leger
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=20200411015522.GK576963@builder.lan \
--to=bjorn.andersson@linaro.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=ohad@wizery.com \
--cc=peng.fan@nxp.com \
/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.