Hi Nikita,
On Fri, 28 Feb 2020 at 04:07, <nikita.shubin@xxxxxxxxxxx> wrote:
>
> From: Nikita Shubin <NShubin@xxxxxxxxxx>
>
> .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@xxxxxxxxxx>
> ---
> 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.
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
>
