All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: nikita.shubin@maquefel.me, Nikita Shubin <NShubin@topcon.com>,
	Ohad Ben-Cohen <ohad@wizery.com>,
	linux-remoteproc <linux-remoteproc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] remoteproc: error on kick missing
Date: Mon, 2 Mar 2020 13:43:21 -0800	[thread overview]
Message-ID: <20200302214317.GI210720@yoga> (raw)
In-Reply-To: <CANLsYkyDsJaxO_37qTjEP+aeQju8W2+jhHFRF7+oifBMqJqyng@mail.gmail.com>

On Mon 02 Mar 09:44 PST 2020, Mathieu Poirier wrote:

> Hi Nikita,
> 
> On Fri, 28 Feb 2020 at 04:07, <nikita.shubin@maquefel.me> wrote:
> >
> > From: Nikita Shubin <NShubin@topcon.com>
> >
> > .kick method not set in rproc_ops will result in:
> >
> > 8<--- cut here ---
> > Unable to handle kernel NULL pointer dereference
> >
> > in rproc_virtio_notify, after firmware loading.
> 
> There wasn't any kernel stack trace?  What platform was this observed
> on? I'm afraid we won't be able to move forward with this patch
> without one, or more information on what is happening.
> 
> >
> > refuse to register an rproc-induced virtio device if no kick method was
> > defined for rproc.
> >
> > Signed-off-by: Nikita Shubin <NShubin@topcon.com>
> > ---

Nikita, please include "v2" in the subject and add here (below the ---)
short summary of what changes since v1.

> >  drivers/remoteproc/remoteproc_virtio.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/remoteproc/remoteproc_virtio.c b/drivers/remoteproc/remoteproc_virtio.c
> > index 8c07cb2ca8ba..31a62a0b470e 100644
> > --- a/drivers/remoteproc/remoteproc_virtio.c
> > +++ b/drivers/remoteproc/remoteproc_virtio.c
> > @@ -334,6 +334,13 @@ int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id)
> >         struct rproc_mem_entry *mem;
> >         int ret;
> >
> > +       if (rproc->ops->kick == NULL) {
> > +               ret = -EINVAL;
> > +               dev_err(dev, ".kick method not defined for %s",
> > +                               rproc->name);
> > +               goto out;
> > +       }
> 
> I think it would be better to use WARN_ONCE() in rproc_virtio_notify()
> than prevent a virtio device from being added.  But again I will need
> more information on this case to know for sure.
> 

I reviewed v1 and afaict there's no way rproc->ops->kick would change
and that things wouldn't work without a kick.

So I requested that it should be checked during initialization instead.
Please let me know if I missed some case.

Regards,
Bjorn

> Thanks,
> Mathieu
> 
> > +
> >         /* Try to find dedicated vdev buffer carveout */
> >         mem = rproc_find_carveout_by_name(rproc, "vdev%dbuffer", rvdev->index);
> >         if (mem) {
> > --
> > 2.24.1
> >

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: nikita.shubin@maquefel.me, Nikita Shubin <NShubin@topcon.com>,
	Ohad Ben-Cohen <ohad@wizery.com>,
	linux-remoteproc <linux-remoteproc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] remoteproc: error on kick missing
Date: Mon, 2 Mar 2020 13:43:17 -0800	[thread overview]
Message-ID: <20200302214317.GI210720@yoga> (raw)
In-Reply-To: <CANLsYkyDsJaxO_37qTjEP+aeQju8W2+jhHFRF7+oifBMqJqyng@mail.gmail.com>

On Mon 02 Mar 09:44 PST 2020, Mathieu Poirier wrote:

> Hi Nikita,
> 
> On Fri, 28 Feb 2020 at 04:07, <nikita.shubin@maquefel.me> wrote:
> >
> > From: Nikita Shubin <NShubin@topcon.com>
> >
> > .kick method not set in rproc_ops will result in:
> >
> > 8<--- cut here ---
> > Unable to handle kernel NULL pointer dereference
> >
> > in rproc_virtio_notify, after firmware loading.
> 
> There wasn't any kernel stack trace?  What platform was this observed
> on? I'm afraid we won't be able to move forward with this patch
> without one, or more information on what is happening.
> 
> >
> > refuse to register an rproc-induced virtio device if no kick method was
> > defined for rproc.
> >
> > Signed-off-by: Nikita Shubin <NShubin@topcon.com>
> > ---

Nikita, please include "v2" in the subject and add here (below the ---)
short summary of what changes since v1.

> >  drivers/remoteproc/remoteproc_virtio.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/remoteproc/remoteproc_virtio.c b/drivers/remoteproc/remoteproc_virtio.c
> > index 8c07cb2ca8ba..31a62a0b470e 100644
> > --- a/drivers/remoteproc/remoteproc_virtio.c
> > +++ b/drivers/remoteproc/remoteproc_virtio.c
> > @@ -334,6 +334,13 @@ int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id)
> >         struct rproc_mem_entry *mem;
> >         int ret;
> >
> > +       if (rproc->ops->kick == NULL) {
> > +               ret = -EINVAL;
> > +               dev_err(dev, ".kick method not defined for %s",
> > +                               rproc->name);
> > +               goto out;
> > +       }
> 
> I think it would be better to use WARN_ONCE() in rproc_virtio_notify()
> than prevent a virtio device from being added.  But again I will need
> more information on this case to know for sure.
> 

I reviewed v1 and afaict there's no way rproc->ops->kick would change
and that things wouldn't work without a kick.

So I requested that it should be checked during initialization instead.
Please let me know if I missed some case.

Regards,
Bjorn

> Thanks,
> Mathieu
> 
> > +
> >         /* Try to find dedicated vdev buffer carveout */
> >         mem = rproc_find_carveout_by_name(rproc, "vdev%dbuffer", rvdev->index);
> >         if (mem) {
> > --
> > 2.24.1
> >

  reply	other threads:[~2020-03-02 21:43 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-28 11:08 [PATCH] remoteproc: error on kick missing nikita.shubin
2020-02-28 11:08 ` nikita.shubin
2020-03-02 17:44 ` Mathieu Poirier
2020-03-02 21:43   ` Bjorn Andersson [this message]
2020-03-02 21:43     ` Bjorn Andersson
2020-03-03 15:56     ` Mathieu Poirier
2020-03-04 14:09       ` nikita.shubin
2020-03-04 16:11         ` Mathieu Poirier
2020-03-05 11:02 ` [PATCH v3 0/1] remoteproc: Fix NULL pointer dereference in rproc_virtio_notify Nikita Shubin
2020-03-05 11:02   ` Nikita Shubin
2020-03-05 11:02   ` [PATCH v3 1/1] " Nikita Shubin
2020-03-05 11:02     ` Nikita Shubin
2020-03-06  7:03     ` [PATCH v4] " Nikita Shubin
2020-03-06  7:03       ` Nikita Shubin
2020-03-06  7:24       ` [PATCH v5] " Nikita Shubin
2020-03-06  7:24         ` Nikita Shubin
2020-03-07 23:20         ` Sasha Levin
2020-03-09 14:22         ` Arnaud POULIQUEN
2020-03-09 14:22           ` Arnaud POULIQUEN
2020-03-10 12:08           ` Nikita Shubin
2020-03-10 13:19             ` Arnaud POULIQUEN
2020-03-10 13:19               ` Arnaud POULIQUEN
2020-03-11 20:01               ` Bjorn Andersson
2020-03-11 20:01                 ` Bjorn Andersson
2020-03-16 16:55                 ` Mathieu Poirier
2020-03-17 14:24                 ` Arnaud POULIQUEN
2020-03-21 17:57                   ` Bjorn Andersson
2020-03-21 17:57                     ` Bjorn Andersson
2020-03-26  5:46         ` patchwork-bot+linux-remoteproc
2020-03-07 23:20       ` [PATCH v4] " Sasha Levin
2020-03-07 23:20     ` [PATCH v3 1/1] " Sasha Levin
2020-03-26  5:47 ` [PATCH] remoteproc: error on kick missing patchwork-bot+linux-remoteproc

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=20200302214317.GI210720@yoga \
    --to=bjorn.andersson@linaro.org \
    --cc=NShubin@topcon.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=nikita.shubin@maquefel.me \
    --cc=ohad@wizery.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.