From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202512 header.b=kCbaghld; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id B4C2B5A004E for ; Fri, 09 Jan 2026 00:38:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202512; t=1767915517; bh=SjV6FCaL/V+yuThVMddZG2stsH/rD1+ZSV1wvHofcEQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kCbaghldPagHhel1Sa2gSAooSHgRdx4FUy12Dfkofv1jHCqAeWsH+hy2gEhe/owEL 58bSFxEjyf+cDI9DbMND4HYWrtnwUe6TlHu2mGwYURp5KUkDoAoXxf8WqnBtVLYQF7 +zREOpITqZ9XzjSad9BDKuYMWDdMBQSU0ZIo/2xgPkGYua/y4EX9ie4dMZPXA1b5lx /VUSri1/kI/mVo8sBMNwjIiYmn0QtDf2Pqw4bNQB3dlGqsvrF02LPNk8v6TajmF0kh Kr4rSzEuK8fWM0fQMfyFoyG3d/3i00oRP3cNK+8HqQEjmLCgxP+PyTG32p87rJPRew +Ruz1lRy9HYFA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4dnLvK3nvLz4wR9; Fri, 09 Jan 2026 10:38:37 +1100 (AEDT) Date: Fri, 9 Jan 2026 10:38:29 +1100 From: David Gibson To: Laurent Vivier Subject: Re: [PATCH v2] udp_vu: Discard datagrams when RX virtqueue is not usable Message-ID: References: <20260107080809.3440007-1-lvivier@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JEsI9Ric+8DQa4h8" Content-Disposition: inline In-Reply-To: Message-ID-Hash: NPYB6PWAANRIYSH6F5SR7353CF57647J X-Message-ID-Hash: NPYB6PWAANRIYSH6F5SR7353CF57647J X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --JEsI9Ric+8DQa4h8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 08, 2026 at 08:13:03AM +0100, Laurent Vivier wrote: > On 1/8/26 00:48, David Gibson wrote: > > On Wed, Jan 07, 2026 at 09:08:09AM +0100, Laurent Vivier wrote: > > > During vhost-user device initialization, UDP datagrams may arrive on > > > listening sockets before the guest has enabled the RX virtqueue. > > >=20 > > > 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. > > >=20 > > > To avoid that, we need to discard the data when the virtqueue is not > > > ready. udp_buf_sock_to_tap() actually does the same as it reads data > > > with udp_sock_recv() and if fd_tap is not initialized tap_send_frames= () > > > drops them. > > >=20 > > > Fixes: 28997fcb29b5 ("vhost-user: add vhost-user") > > > Link: https://bugs.passt.top/show_bug.cgi?id=3D185 > > > Signed-off-by: Laurent Vivier > >=20 > > Reviewed-by: David Gibson > >=20 > > Although one possible nit noted.. > >=20 > > > --- > > >=20 > > > Notes: > > > v2: > > > - move recvmsg() from udp_vu_sock_to_tap() to udp_vu_sock_recv= () > > >=20 > > > udp_vu.c | 32 ++++++++++++++++++++++---------- > > > 1 file changed, 22 insertions(+), 10 deletions(-) > > >=20 > > > diff --git a/udp_vu.c b/udp_vu.c > > > index c30dcf97698f..3774d538a2d0 100644 > > > --- a/udp_vu.c > > > +++ b/udp_vu.c > > > @@ -65,7 +65,8 @@ static size_t udp_vu_hdrlen(bool v6) > > > * @v6: Set for IPv6 connections > > > * @dlen: Size of received data (output) > > > * > > > - * Return: number of iov entries used to store the datagram > > > + * Return: number of iov entries used to store the datagram, 0 if th= e datagram > > > + * was discarded because the virtqueue is not ready, -1 on e= rror > > > */ > > > static int udp_vu_sock_recv(const struct ctx *c, struct vu_virtq *v= q, int s, > > > bool v6, ssize_t *dlen) > > > @@ -77,6 +78,15 @@ static int udp_vu_sock_recv(const struct ctx *c, s= truct vu_virtq *vq, int s, > > > ASSERT(!c->no_udp); > > > + if (!vu_queue_enabled(vq) || !vu_queue_started(vq)) { > > > + debug("Got UDP packet, but RX virtqueue not usable yet"); > > > + > > > + if (recvmsg(s, &msg, MSG_DONTWAIT) < 0) > >=20 > > You use MSG_DONTWAIT here, but you don't on the normal path. I guess > > it shouldn't make a difference, since we've come from epoll so we know > > something is waiting for us. But I think we want to make the paths > > look as identical as we can from the point of view of the socket side, > > and this makes it a bit less obvious. >=20 > This is actually consistent with the existing discard pattern in > udp_sock_fwd(). When udp_sock_fwd() needs to discard a datagram, it does > exactly the same thing: >=20 > if (discard) { > struct msghdr msg =3D { 0 }; >=20 > if (recvmsg(s, &msg, MSG_DONTWAIT) < 0) > debug_perror("Failed to discard datagram"); > } Ah, true. I'd say it's a nit there, too. > udp_sock_fwd() loops on udp_peek_addr(), calls udp_vu_sock_to_tap() (and= then > udp_vu_sock_recv()). If something has to be discarded it calls > recvmsg(s, &msg, MSG_DONTWAIT). Ah, that's a point. The fact we've just MSG_PEEKed means that we can be certain there is something in the queue, making it more obvious that MSG_DONTWAIT won't have any effect. Anyway, Reviewed-by: David Gibson --=20 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 --JEsI9Ric+8DQa4h8 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmlgP/UACgkQzQJF27ox 2GcWgg//WzantB7LVl1LumWXlwohNz6Os7Rv2d6MXvT0n2ngi0kejFWr8LtbBbvs t9WoDA+bhczTm5WVu4IpL1k4AER5EakazJNTPaNDQYBjDhsvlaS/HXBoLJ9GRXaO d9t8GE5iFruLusSQXkoompZs7ROWDF9PWs3pIJitUWoSEFr8mF/djJXo1RRdFLcw LCZ8mQtjtcGc8J2BEx6TI8jGrUa2qeSHf3oerv5U/pNJT3SfI57g38tYW7DMU8dS 4FBlfV2awJEXpbSA1J5tiFa2Gr0148Wghiny/csyIUudJN7yj7P3vKLjEIyhHpHh Nsr6+IUUnwirW89ZN2fJjbz2VlseYqK6xadNrVk8JXb0WA+Pp596V7HR+aLUAAWQ l/X8OTMMRzA7EJnlhQk9pZYWIhyi0/MOgUIZME6qnVpVUofPMhF7hGz1FEI7VDTS hDc2uISAC9lF53wVfWxcaoTO6OANknf+LqtwPx8cARYxhPDrttxAd6kIbwFwG6Jx W/WPmZQYoxKu4h2ux3U7BgPkyszUQBKI9J2u0qcdfzcnUCXsk9PnhUUus5qlQK3h 51WrnqF8Ia7im8hnjHl1c/vx3WQrSpIqHEuVG6sd7wCL3ubm5Dgv12sJDwxLcb8U uyVQ1kUFwDEc7cYWu0Pghk/94UlLOrWRD7mUwXgX3XnWA+krQrY= =Nggz -----END PGP SIGNATURE----- --JEsI9Ric+8DQa4h8--