LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
	Ohad Ben-Cohen <ohad@wizery.com>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	<linux-remoteproc@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-stm32@st-md-mailman.stormreply.com>,
	Jason Wang <jasowang@redhat.com>
Subject: Re: [PATCH] rpmsg: virtio: don't let virtio core to validate used length
Date: Tue, 23 Nov 2021 14:31:20 +0100	[thread overview]
Message-ID: <43894114-6d25-98fa-a89f-b720749ba910@foss.st.com> (raw)
In-Reply-To: <20211123011340-mutt-send-email-mst@kernel.org>

Hello Mickael, Jason,

On 11/23/21 7:15 AM, Michael S. Tsirkin wrote:
> On Mon, Nov 22, 2021 at 05:08:12PM +0100, Arnaud Pouliquen wrote:
>> For RX virtqueue, the used length is validated in all the three paths
>> (big, small and mergeable). For control vq, we never tries to use used
>> length. So this patch forbids the core to validate the used length.
> 
> Jason commented on this. This is copy paste from virtio net
> where the change was merely an optimization.
> 

Right, I did it too fast last night (European time) to share the regression as
soon as possible.
For that, I copied and pasted the first commit I found related to the problem.
Need to rework this.

>> Without patch the rpmsg client sample does not work.
> 
> Hmm that's not enough of a description. Could you please
> provide more detail? Does rpmsg device set used length to a
> value > dma read buffer size? what kind of error message
> do you get? what are the plans to fix the device?

Let's me explain the context.
I run the rpmsg client sample test to communicate with a remote processor
that runs a Zephyr FW designed to answer to the Linux kernel driver sample.

The Zephyr is relying on OpenAMP library to implement the RPMsg and VirtIO layers.

In TX direction (Linux to Zephyr) 8 buffers of 512 bytes are allocated.
The first 8 RPMsg sent are OK. But when virtio loop back the the TX buffer index
0 (so already used and free one time) the following error occurs in
virtqueue_get_buf_ctx_split[1]:
" virtio_rpmsg_bus virtio0: output:used len 28 is larger than in buflen 0"

I have investigated the problem further today. Here is my analysis

rpmsg_send_offchannel_raw
-> virtqueue_add_outbuf
   -> virtqueue_add
      -> virtqueue_add_split
	 Here we use the "out_sgs" (in_sgs == 0)
	 buflen is not incremented in loop [2]
	 We don't enter in loop [3] as "in_sgs == 0"
	 consequence is that vq->buflen[head] is set to 0 [4]

[1]
https://elixir.bootlin.com/linux/v5.16-rc2/source/drivers/virtio/virtio_ring.c#L799
[2]
https://elixir.bootlin.com/linux/v5.16-rc2/source/drivers/virtio/virtio_ring.c#L551
[3]
https://elixir.bootlin.com/linux/v5.16-rc2/source/drivers/virtio/virtio_ring.c#L567
[4]
https://elixir.bootlin.com/linux/v5.16-rc2/source/drivers/virtio/virtio_ring.c#L622


An alternative to fix the issue is to set buflen in loop 2, but I'm not enough
expert to ensure that this will not have any side effect...

@@ -559,10 +559,11 @@ static inline int virtqueue_add_split(struct virtqueue *_vq,
 			 * table since it use stream DMA mapping.
 			 */
 			i = virtqueue_add_desc_split(_vq, desc, i, addr, sg->length,
 						     VRING_DESC_F_NEXT,
 						     indirect);
+			buflen += sg->length;
 		}
 	}
 	for (; n < (out_sgs + in_sgs); n++) {

So can you tell me if you prefer me to send a V2 updating the commit message or
a new message to fix virtio_ring (or both)?

Thanks,
Arnaud

> 
>> Fixes: 939779f5152d ("virtio_ring: validate used buffer length")
>>
>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
>> Cc: Jason Wang <jasowang@redhat.com>
>> Cc: Michael S. Tsirkin <mst@redhat.com>
>> ---
>> base-commit: fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf
>> ---
>>  drivers/rpmsg/virtio_rpmsg_bus.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
>> index 9c112aa65040..5f73f19c2c38 100644
>> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
>> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
>> @@ -1054,6 +1054,7 @@ static struct virtio_driver virtio_ipc_driver = {
>>  	.feature_table_size = ARRAY_SIZE(features),
>>  	.driver.name	= KBUILD_MODNAME,
>>  	.driver.owner	= THIS_MODULE,
>> +	.suppress_used_validation = true,
>>  	.id_table	= id_table,
>>  	.probe		= rpmsg_probe,
>>  	.remove		= rpmsg_remove,
>> -- 
>> 2.17.1
> 

  reply	other threads:[~2021-11-23 13:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-22 16:08 Arnaud Pouliquen
2021-11-23  2:15 ` Jason Wang
2021-11-23  2:16   ` Jason Wang
2021-11-23  6:15 ` Michael S. Tsirkin
2021-11-23 13:31   ` Arnaud POULIQUEN [this message]
2021-11-24  2:12     ` Jason Wang
2021-11-24 15:48       ` Arnaud POULIQUEN

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=43894114-6d25-98fa-a89f-b720749ba910@foss.st.com \
    --to=arnaud.pouliquen@foss.st.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=jasowang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mathieu.poirier@linaro.org \
    --cc=mst@redhat.com \
    --cc=ohad@wizery.com \
    --subject='Re: [PATCH] rpmsg: virtio: don'\''t let virtio core to validate used length' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).