public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Peng Fan <peng.fan@nxp.com>,
	ohad@wizery.com, linux-remoteproc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-imx@nxp.com
Subject: Re: [PATCH 2/2] remoteproc: use filesz as backup when translate memsz fail
Date: Fri, 17 Apr 2020 13:21:55 -0600	[thread overview]
Message-ID: <20200417192155.GA6797@xps15> (raw)
In-Reply-To: <20200410012226.GV20625@builder.lan>

On Thu, Apr 09, 2020 at 06:22:26PM -0700, Bjorn Andersson wrote:
> 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.
> 
> 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;
> > +			}
> > +

Adding to Bjorn's comment, I think if rproc_da_to_va() fails with memsz but
succeeds with filesz something went wrong with how memory was laid out in the
DT or the ELF resources.  To me this patch offers the wrong solution - the
focus should be on why rproc_da_to_va() fails.

Thanks,
Mathieu  

> >  		}
> >  
> >  		/* put the segment where the remote processor expects it */
> > -- 
> > 2.16.4
> > 

  parent reply	other threads:[~2020-04-17 19:22 UTC|newest]

Thread overview: 15+ 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:32     ` Peng Fan
2020-04-11  1:55       ` Bjorn Andersson
2020-04-17 19:21     ` Mathieu Poirier [this message]
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:29   ` Peng Fan
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=20200417192155.GA6797@xps15 \
    --to=mathieu.poirier@linaro.org \
    --cc=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox