All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaud POULIQUEN <arnaud.pouliquen@st.com>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Nikita Shubin <nshubin@topcon.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	Ohad Ben-Cohen <ohad@wizery.com>,
	"linux-remoteproc@vger.kernel.org"
	<linux-remoteproc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>
Subject: Re: [PATCH v5] remoteproc: Fix NULL pointer dereference in rproc_virtio_notify
Date: Tue, 17 Mar 2020 15:24:53 +0100	[thread overview]
Message-ID: <f6de2571-3541-7004-bc57-92cb3fef2c71@st.com> (raw)
In-Reply-To: <20200311200107.GZ1214176@minitux>

Hi Bjorn

On 3/11/20 9:01 PM, Bjorn Andersson wrote:
> On Tue 10 Mar 06:19 PDT 2020, Arnaud POULIQUEN wrote:
> 
>>
>>
>>> -----Original Message-----
>>> From: linux-remoteproc-owner@vger.kernel.org <linux-remoteproc-
>>> owner@vger.kernel.org> On Behalf Of Nikita Shubin
>>> Sent: mardi 10 mars 2020 13:09
>>> To: Arnaud POULIQUEN <arnaud.pouliquen@st.com>
>>> Cc: stable@vger.kernel.org; Ohad Ben-Cohen <ohad@wizery.com>; Bjorn
>>> Andersson <bjorn.andersson@linaro.org>; linux-
>>> remoteproc@vger.kernel.org; linux-kernel@vger.kernel.org; Mathieu Poirier
>>> <mathieu.poirier@linaro.org>
>>> Subject: Re: [PATCH v5] remoteproc: Fix NULL pointer dereference in
>>> rproc_virtio_notify
>>>
>>> On Mon, Mar 09, 2020 at 03:22:24PM +0100, Arnaud POULIQUEN wrote:
>>>> Hi,
>>>>
>>>> sorry for the late answer...
>>>>
>>>> On 3/6/20 8:24 AM, Nikita Shubin wrote:
>>>>> Undefined rproc_ops .kick method in remoteproc driver will result in
>>>>> "Unable to handle kernel NULL pointer dereference" in
>>>>> rproc_virtio_notify, after firmware loading if:
>>>>>
>>>>>  1) .kick method wasn't defined in driver
>>>>>  2) resource_table exists in firmware and has "Virtio device entry"
>>>>> defined
>>>>>
>>>>> Let's refuse to register an rproc-induced virtio device if no kick
>>>>> method was defined for rproc.
>>>>>

[...]

>>>>>
>>>>> Signed-off-by: Nikita Shubin <NShubin@topcon.com>
>>>>> Fixes: 7a186941626d ("remoteproc: remove the single rpmsg vdev
>>>>> limitation")
>>>>> Cc: stable@vger.kernel.org
>>>>> ---
>>>>>  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;
>>>>> +	}
>>>>> +
>>>> Should the kick ops be mandatory for all the platforms? How about making
>>> it optional instead?
>>>
>>> Hi, Arnaud.
>>>
>>> It is not mandatory, currently it must be provided if specified vdev entry is in
>>> resourse table. Otherwise it looks like there is no point in creating vdev.
>>
>> Yes, my question was about having it optional for vdev also. A platform could implement the vdev
>> without kick mechanism but by polling depending due to hardware capability...
>> This could be an alternative avoiding to implement a dummy function in platform driver.
>>
> 
> Is this a real thing or a theoretical suggestion?
Only a theoretical suggestion, trigged by the IMX platform patchset which implement a "temporary" dummy kick.
and based on OpenAMP lib implementation which does not request a doorbell.
Anyway no issue to keep it mandatory here. 

Regards,
Arnaud

> 
> Regards,
> Bjorn
> 
>> Anyway it just a proposal that makes sense from MPOV. If Bjorn is ok with your patch, nothing blocking on my side.
>>
>> Regards
>> Arnaud
>>
>>>
>>>
>>>>
>>>> Regards,
>>>> Arnaud
>>>>
>>>>>  	/* Try to find dedicated vdev buffer carveout */
>>>>>  	mem = rproc_find_carveout_by_name(rproc, "vdev%dbuffer",
>>> rvdev->index);
>>>>>  	if (mem) {
>>>>>

  parent reply	other threads:[~2020-03-17 14:24 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
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 [this message]
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=f6de2571-3541-7004-bc57-92cb3fef2c71@st.com \
    --to=arnaud.pouliquen@st.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=nshubin@topcon.com \
    --cc=ohad@wizery.com \
    --cc=stable@vger.kernel.org \
    /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.