Stefano Garzarella
2020-Apr-21 09:25 UTC
[PATCH net] vsock/virtio: postpone packet delivery to monitoring devices
We delivering packets to monitoring devices, before to check if the virtqueue has enough space. If the virtqueue is full, the transmitting packet is queued up and it will be sent in the next iteration. This causes the same packet to be delivered multiple times to monitoring devices. This patch fixes this issue, postponing the packet delivery to monitoring devices, only when it is properly queued in the virqueue. Fixes: 82dfb540aeb2 ("VSOCK: Add virtio vsock vsockmon hooks") Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- net/vmw_vsock/virtio_transport.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c index dfbaf6bd8b1c..d8db837a96fe 100644 --- a/net/vmw_vsock/virtio_transport.c +++ b/net/vmw_vsock/virtio_transport.c @@ -115,8 +115,6 @@ virtio_transport_send_pkt_work(struct work_struct *work) list_del_init(&pkt->list); spin_unlock_bh(&vsock->send_pkt_list_lock); - virtio_transport_deliver_tap_pkt(pkt); - reply = pkt->reply; sg_init_one(&hdr, &pkt->hdr, sizeof(pkt->hdr)); @@ -137,6 +135,11 @@ virtio_transport_send_pkt_work(struct work_struct *work) break; } + /* Deliver to monitoring devices all correctly transmitted + * packets. + */ + virtio_transport_deliver_tap_pkt(pkt); + if (reply) { struct virtqueue *rx_vq = vsock->vqs[VSOCK_VQ_RX]; int val; -- 2.25.3
Stefan Hajnoczi
2020-Apr-21 15:42 UTC
[PATCH net] vsock/virtio: postpone packet delivery to monitoring devices
On Tue, Apr 21, 2020 at 11:25:27AM +0200, Stefano Garzarella wrote:> We delivering packets to monitoring devices, before to check if > the virtqueue has enough space."We [are] delivering packets" and "before to check" -> "before checking". Perhaps it can be rewritten as: Packets are delivered to monitoring devices before checking if the virtqueue has enough space.> > If the virtqueue is full, the transmitting packet is queued up > and it will be sent in the next iteration. This causes the same > packet to be delivered multiple times to monitoring devices. > > This patch fixes this issue, postponing the packet delivery > to monitoring devices, only when it is properly queued in thes/,//> virqueue.s/virqueue/virtqueue/> @@ -137,6 +135,11 @@ virtio_transport_send_pkt_work(struct work_struct *work) > break; > } > > + /* Deliver to monitoring devices all correctly transmitted > + * packets. > + */ > + virtio_transport_deliver_tap_pkt(pkt); > +The device may see the tx packet and therefore receive a reply to it before we can call virtio_transport_deliver_tap_pkt(). Does this mean that replies can now appear in the packet capture before the transmitted packet? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20200421/e1f8a240/attachment.sig>
Stefano Garzarella
2020-Apr-21 16:17 UTC
[PATCH net] vsock/virtio: postpone packet delivery to monitoring devices
On Tue, Apr 21, 2020 at 04:42:46PM +0100, Stefan Hajnoczi wrote:> On Tue, Apr 21, 2020 at 11:25:27AM +0200, Stefano Garzarella wrote: > > We delivering packets to monitoring devices, before to check if > > the virtqueue has enough space. > > "We [are] delivering packets" and "before to check" -> "before > checking". Perhaps it can be rewritten as: > > Packets are delivered to monitoring devices before checking if the > virtqueue has enough space. >Yeah, it is better :-)> > > > If the virtqueue is full, the transmitting packet is queued up > > and it will be sent in the next iteration. This causes the same > > packet to be delivered multiple times to monitoring devices. > > > > This patch fixes this issue, postponing the packet delivery > > to monitoring devices, only when it is properly queued in the > > s/,// > > > virqueue. > > s/virqueue/virtqueue/ >Thanks, I'll fix in the v2!> > @@ -137,6 +135,11 @@ virtio_transport_send_pkt_work(struct work_struct *work) > > break; > > } > > > > + /* Deliver to monitoring devices all correctly transmitted > > + * packets. > > + */ > > + virtio_transport_deliver_tap_pkt(pkt); > > + > > The device may see the tx packet and therefore receive a reply to it > before we can call virtio_transport_deliver_tap_pkt(). Does this mean > that replies can now appear in the packet capture before the transmitted > packet?hmm, you are right! And the same thing can already happen in vhost-vsock where we call virtio_transport_deliver_tap_pkt() after the vhost_add_used(), right? The vhost-vsock case can be fixed in a simple way, but here do you think we should serialize them? (e.g. mutex, spinlock) In this case I'm worried about performance. Or is there some virtqueue API to check availability? Thanks, Stefano
Maybe Matching Threads
- [PATCH net] vsock/virtio: postpone packet delivery to monitoring devices
- [PATCH net] vsock/virtio: postpone packet delivery to monitoring devices
- [PATCH net] vsock/virtio: postpone packet delivery to monitoring devices
- [PATCH net v2 0/2] vsock/virtio: fixes about packet delivery to monitoring devices
- [PATCH net] vsock/virtio: postpone packet delivery to monitoring devices