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