[PATCH] udp_vu: Discard datagrams when RX virtqueue is not usable

[PATCH] udp_vu: Discard datagrams when RX virtqueue is not usable

[Laurent Vivier]

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 <lvivier@redhat.com>
---
 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

Re: [PATCH] udp_vu: Discard datagrams when RX virtqueue is not usable

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2233 bytes --]

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 <lvivier@redhat.com>

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] udp_vu: Discard datagrams when RX virtqueue is not usable

[Laurent Vivier]

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 <lvivier@redhat.com>
> 
> 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
>>
> 

Re: [PATCH] udp_vu: Discard datagrams when RX virtqueue is not usable

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]

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 <lvivier@redhat.com>
> > 
> > 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]