similar to: [PATCH v3] virtio_net: suppress cpu stall when free_unused_bufs

On Fri, May 05, 2023 at 11:28:25AM +0800, Jason Wang wrote: > On Thu, May 4, 2023 at 10:27?AM Wenliang Wang > <wangwenliang.1995 at bytedance.com> wrote: > > > > For multi-queue and large ring-size use case, the following error > > occurred when free_unused_bufs: > > rcu: INFO: rcu_sched self-detected stall on CPU. > > > > Fixes: 986a4f4d452d

On Thu, May 4, 2023 at 10:27?AM Wenliang Wang <wangwenliang.1995 at bytedance.com> wrote: > > For multi-queue and large ring-size use case, the following error > occurred when free_unused_bufs: > rcu: INFO: rcu_sched self-detected stall on CPU. > > Fixes: 986a4f4d452d ("virtio_net: multiqueue support") > Signed-off-by: Wenliang Wang <wangwenliang.1995 at

On Thu, May 04, 2023 at 10:27:06AM +0800, Wenliang Wang wrote: > For multi-queue and large ring-size use case, the following error > occurred when free_unused_bufs: > rcu: INFO: rcu_sched self-detected stall on CPU. > > Fixes: 986a4f4d452d ("virtio_net: multiqueue support") > Signed-off-by: Wenliang Wang <wangwenliang.1995 at bytedance.com> Acked-by: Michael S.

On Fri, Jun 02, 2023 at 05:22:06PM +0800, Xuan Zhuo wrote: > Introduce the module param "experiment_premapped" to enable the function > that the virtio-net do dma mapping. > > If that is true, the vq of virtio-net is under the premapped mode. > It just handle the sg with dma_address. And the driver must get the dma > address of the buffer to unmap after get the buffer

Here we copy the data from the original buf to the new page. But we not check that it may be overflow. As long as the size received(including vnethdr) is greater than 3840 (PAGE_SIZE -VIRTIO_XDP_HEADROOM). Then the memcpy will overflow. And this is completely possible, as long as the MTU is large, such as 4096. In our test environment, this will cause crash. Since crash is caused by the written

Here we copy the data from the original buf to the new page. But we not check that it may be overflow. As long as the size received(including vnethdr) is greater than 3840 (PAGE_SIZE -VIRTIO_XDP_HEADROOM). Then the memcpy will overflow. And this is completely possible, as long as the MTU is large, such as 4096. In our test environment, this will cause crash. Since crash is caused by the written

On 12/05/2013 10:36 PM, Andrey Vagin wrote: > free_unused_bufs must check vi->mergeable_rx_bufs before > vi->big_packets, because we use this sequence in other places. > Otherwise we allocate buffer of one type, then free it as another > type. > > general protection fault: 0000 [#1] SMP > Dumping ftrace buffer: > (ftrace buffer empty) > Modules linked in:

On 12/05/2013 10:36 PM, Andrey Vagin wrote: > free_unused_bufs must check vi->mergeable_rx_bufs before > vi->big_packets, because we use this sequence in other places. > Otherwise we allocate buffer of one type, then free it as another > type. > > general protection fault: 0000 [#1] SMP > Dumping ftrace buffer: > (ftrace buffer empty) > Modules linked in:

On Thu, Dec 05, 2013 at 06:36:20PM +0400, Andrey Vagin wrote: > free_unused_bufs must check vi->mergeable_rx_bufs before > vi->big_packets, because we use this sequence in other places. > Otherwise we allocate buffer of one type, then free it as another > type. > > general protection fault: 0000 [#1] SMP > Dumping ftrace buffer: > (ftrace buffer empty) >

free_unused_bufs must check vi->mergeable_rx_bufs before vi->big_packets, because we use this sequence in other places. Otherwise we allocate buffer of one type, then free it as another type. general protection fault: 0000 [#1] SMP Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: ip6table_filter ip6_tables iptable_filter ip_tables pcspkr virtio_balloon virtio_net(-)

We free the skb immediately on kick failure during xmit without detaching it from the virtqueue. This may lead double free for the skb during free_unused_bufs(). This patch fixes this by not freeing it on kick failure and let it to be freed through free_unused_bufs(). Fixes 67975901183799af8e93ec60e322f9e2a1940b9b ("virtio_net: verify if virtqueue_kick() succeeded"). Cc: Rusty Russell

We free the skb immediately on kick failure during xmit without detaching it from the virtqueue. This may lead double free for the skb during free_unused_bufs(). This patch fixes this by not freeing it on kick failure and let it to be freed through free_unused_bufs(). Fixes 67975901183799af8e93ec60e322f9e2a1940b9b ("virtio_net: verify if virtqueue_kick() succeeded"). Cc: Rusty Russell

On 03/23/2014 07:27 PM, Michael S. Tsirkin wrote: > On Fri, Mar 21, 2014 at 04:30:01PM +0800, Jason Wang wrote: >> We free the skb immediately on kick failure during xmit without detaching it >> from the virtqueue. This may lead double free for the skb during >> free_unused_bufs(). This patch fixes this by not freeing it on kick failure and >> let it to be freed through

On 03/23/2014 07:27 PM, Michael S. Tsirkin wrote: > On Fri, Mar 21, 2014 at 04:30:01PM +0800, Jason Wang wrote: >> We free the skb immediately on kick failure during xmit without detaching it >> from the virtqueue. This may lead double free for the skb during >> free_unused_bufs(). This patch fixes this by not freeing it on kick failure and >> let it to be freed through

On Fri, Mar 21, 2014 at 04:30:01PM +0800, Jason Wang wrote: > We free the skb immediately on kick failure during xmit without detaching it > from the virtqueue. This may lead double free for the skb during > free_unused_bufs(). This patch fixes this by not freeing it on kick failure and > let it to be freed through free_unused_bufs(). > > Fixes

Jason Wang <jasowang at redhat.com> writes: > It looks like there's no need for those two fields: > > - Unless there's a failure for the first refill try, rq->max should be always > equal to the vring size. > - rq->num is only used to determine the condition that we need to do the refill, > we could check vq->num_free instead. > - rq->num was

It looks like there's no need for those two fields: - Unless there's a failure for the first refill try, rq->max should be always equal to the vring size. - rq->num is only used to determine the condition that we need to do the refill, we could check vq->num_free instead. - rq->num was required to be increased or decreased explicitly after each get/put which results a

It looks like there's no need for those two fields: - Unless there's a failure for the first refill try, rq->max should be always equal to the vring size. - rq->num is only used to determine the condition that we need to do the refill, we could check vq->num_free instead. - rq->num was required to be increased or decreased explicitly after each get/put which results a

It looks like there's no need for those two fields: - Unless there's a failure for the first refill try, rq->max should be always equal to the vring size. - rq->num is only used to determine the condition that we need to do the refill, we could check vq->num_free instead. - rq->num was required to be increased or decreased explicitly after each get/put which results a

It looks like there's no need for those two fields: - Unless there's a failure for the first refill try, rq->max should be always equal to the vring size. - rq->num is only used to determine the condition that we need to do the refill, we could check vq->num_free instead. - rq->num was required to be increased or decreased explicitly after each get/put which results a