[PATCH] udp_vu: Discard datagrams when RX virtqueue is not usable
During vhost-user device initialization, UDP datagrams may arrive on
listening sockets before the guest has enabled the RX virtqueue.
When this happens, udp_vu_sock_recv() returns 0 without consuming
the datagram from the socket. The caller, udp_sock_fwd(), uses a
while loop with udp_peek_addr() to process pending datagrams. Since
the datagram remains in the socket buffer, udp_peek_addr() keeps
returning data available, causing a busy loop with 100% CPU usage.
Add an early check for virtqueue readiness in udp_vu_sock_to_tap(),
mirroring tcp_vu_data_from_sock(). When the queue is not enabled or
not started, explicitly discard the datagram with recvmsg() and
return. The caller will drain remaining datagrams through repeated
calls.
Fixes: 28997fcb29b5 ("vhost-user: add vhost-user")
Link: https://bugs.passt.top/show_bug.cgi?id=185
Signed-off-by: Laurent Vivier
On Mon, Jan 05, 2026 at 03:50:16PM +0100, Laurent Vivier wrote:
During vhost-user device initialization, UDP datagrams may arrive on listening sockets before the guest has enabled the RX virtqueue.
When this happens, udp_vu_sock_recv() returns 0 without consuming the datagram from the socket. The caller, udp_sock_fwd(), uses a while loop with udp_peek_addr() to process pending datagrams. Since the datagram remains in the socket buffer, udp_peek_addr() keeps returning data available, causing a busy loop with 100% CPU usage.
Add an early check for virtqueue readiness in udp_vu_sock_to_tap(), mirroring tcp_vu_data_from_sock(). When the queue is not enabled or not started, explicitly discard the datagram with recvmsg() and return. The caller will drain remaining datagrams through repeated calls.
Fixes: 28997fcb29b5 ("vhost-user: add vhost-user") Link: https://bugs.passt.top/show_bug.cgi?id=185 Signed-off-by: Laurent Vivier
My only concern here is that this will only consume a single datagram, whereas it looks like the loop could consume multiple datagrams. I'm guessing something higher up will keep calling this until the queue is empty, but I'm not certain. Otherwise LGTM.
--- udp_vu.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/udp_vu.c b/udp_vu.c index c30dcf97698f..67f4ee619bfb 100644 --- a/udp_vu.c +++ b/udp_vu.c @@ -211,6 +211,17 @@ void udp_vu_sock_to_tap(const struct ctx *c, int s, int n, flow_sidx_t tosidx) struct vu_virtq *vq = &vdev->vq[VHOST_USER_RX_QUEUE]; int i;
+ if (!vu_queue_enabled(vq) || !vu_queue_started(vq)) { + struct msghdr msg = { 0 }; + + debug("Got UDP packet, but RX virtqueue not usable yet"); + + if (recvmsg(s, &msg, MSG_DONTWAIT) < 0) + debug_perror("Failed to discard datagram"); + + return; + } + for (i = 0; i < n; i++) { ssize_t dlen; int iov_used; -- 2.52.0
-- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
On 1/6/26 00:28, David Gibson wrote:
On Mon, Jan 05, 2026 at 03:50:16PM +0100, Laurent Vivier wrote:
During vhost-user device initialization, UDP datagrams may arrive on listening sockets before the guest has enabled the RX virtqueue.
When this happens, udp_vu_sock_recv() returns 0 without consuming the datagram from the socket. The caller, udp_sock_fwd(), uses a while loop with udp_peek_addr() to process pending datagrams. Since the datagram remains in the socket buffer, udp_peek_addr() keeps returning data available, causing a busy loop with 100% CPU usage.
Add an early check for virtqueue readiness in udp_vu_sock_to_tap(), mirroring tcp_vu_data_from_sock(). When the queue is not enabled or not started, explicitly discard the datagram with recvmsg() and return. The caller will drain remaining datagrams through repeated calls.
Fixes: 28997fcb29b5 ("vhost-user: add vhost-user") Link: https://bugs.passt.top/show_bug.cgi?id=185 Signed-off-by: Laurent Vivier
My only concern here is that this will only consume a single datagram, whereas it looks like the loop could consume multiple datagrams. I'm guessing something higher up will keep calling this until the queue is empty, but I'm not certain. Otherwise LGTM.
I can move the change into udp_vu_sock_recv() (inside the datagram loop), it will be closer to what udp_buf_sock_to_tap() does: reads data with udp_sock_recv() and if fd_tap is not initialized tap_send_frames() drops them. Thanks, Laurent
--- udp_vu.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/udp_vu.c b/udp_vu.c index c30dcf97698f..67f4ee619bfb 100644 --- a/udp_vu.c +++ b/udp_vu.c @@ -211,6 +211,17 @@ void udp_vu_sock_to_tap(const struct ctx *c, int s, int n, flow_sidx_t tosidx) struct vu_virtq *vq = &vdev->vq[VHOST_USER_RX_QUEUE]; int i;
+ if (!vu_queue_enabled(vq) || !vu_queue_started(vq)) { + struct msghdr msg = { 0 }; + + debug("Got UDP packet, but RX virtqueue not usable yet"); + + if (recvmsg(s, &msg, MSG_DONTWAIT) < 0) + debug_perror("Failed to discard datagram"); + + return; + } + for (i = 0; i < n; i++) { ssize_t dlen; int iov_used; -- 2.52.0
On Tue, Jan 06, 2026 at 08:48:31AM +0100, Laurent Vivier wrote:
On 1/6/26 00:28, David Gibson wrote:
On Mon, Jan 05, 2026 at 03:50:16PM +0100, Laurent Vivier wrote:
During vhost-user device initialization, UDP datagrams may arrive on listening sockets before the guest has enabled the RX virtqueue.
When this happens, udp_vu_sock_recv() returns 0 without consuming the datagram from the socket. The caller, udp_sock_fwd(), uses a while loop with udp_peek_addr() to process pending datagrams. Since the datagram remains in the socket buffer, udp_peek_addr() keeps returning data available, causing a busy loop with 100% CPU usage.
Add an early check for virtqueue readiness in udp_vu_sock_to_tap(), mirroring tcp_vu_data_from_sock(). When the queue is not enabled or not started, explicitly discard the datagram with recvmsg() and return. The caller will drain remaining datagrams through repeated calls.
Fixes: 28997fcb29b5 ("vhost-user: add vhost-user") Link: https://bugs.passt.top/show_bug.cgi?id=185 Signed-off-by: Laurent Vivier
My only concern here is that this will only consume a single datagram, whereas it looks like the loop could consume multiple datagrams. I'm guessing something higher up will keep calling this until the queue is empty, but I'm not certain. Otherwise LGTM.
I can move the change into udp_vu_sock_recv() (inside the datagram loop), it will be closer to what udp_buf_sock_to_tap() does: reads data with udp_sock_recv() and if fd_tap is not initialized tap_send_frames() drops them.
That seems a little safer (or at least, more obviously safe) to me. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
participants (2)
-
David Gibson
-
Laurent Vivier