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=202602 header.b=N+yUUh/L; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 79EC85A0269 for ; Mon, 18 May 2026 04:54:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202602; t=1779072890; bh=z/yBib73bGjrYEmPajLPOSlz7CADYLhOxEvFYCt4rxM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=N+yUUh/LqGbQ+QAPOHPaFU+PQu4o0bd73ba1YrgGC5V4Wrokxqs+M4o8oyAaRauGc 4gEnD/mc7N5FEobzwF1KP9nk8XF0kDQ6IhgwbyyxQVWjR5PEJcsN8VTbN0LwlN53hI er2JCHjNZZVLwWWtxdkJ9YCgpouHtbNxaZ1pQbExKueOorHDKPDFS81cifcLOY2Poe DMLdHiL6WyW6t7LvMGwAWmCwBkK4sO4/d6ULVQ8gC8FvvU7O6y1W/sa/ilc4BEJrv4 TgnmKQe44BJxq+56VDw9QroI/WglFO35u7u3UJ4k3Quwh4S9RWcJg1T37bpEpVBSQH sAlRNjCzZsrXQ== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4gJj8B4Jdjz4wTM; Mon, 18 May 2026 12:54:50 +1000 (AEST) Date: Mon, 18 May 2026 12:50:01 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 3/3] conf, repair, tap: More caution about blocking flag on Unix sockets Message-ID: References: <20260513041423.2446716-1-david@gibson.dropbear.id.au> <20260513041423.2446716-4-david@gibson.dropbear.id.au> <20260516174615.0cb33d6e@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hvier0rT/H0S2TiO" Content-Disposition: inline In-Reply-To: <20260516174615.0cb33d6e@elisabeth> Message-ID-Hash: XJG5N722JSD7H6QNDQZQYDJ6YG4ZJ32F X-Message-ID-Hash: XJG5N722JSD7H6QNDQZQYDJ6YG4ZJ32F 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: --hvier0rT/H0S2TiO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 16, 2026 at 05:46:16PM +0200, Stefano Brivio wrote: > On Wed, 13 May 2026 14:14:23 +1000 > David Gibson wrote: >=20 > > Most of our operation is asynchronous, based on non-blocking fds handled > > in our epoll loop. However, our several Unix sockets (tap client, repa= ir > > helper, control client) are all blocking fds after accept(). > >=20 > > That's correct for the repair helper, and (for now) correct for the con= trol > > client. However, the reasons for that might not be obvious, so add some > > extra comments giving the rationale. > >=20 > > I don't believe it's correct for the tap client; having this socket be > > blocking means we could potentially block the main loop if we ever got a > > a spurious EPOLL{IN,OUT} event on the tap socket. Switch the tap socket > > to non-blocking for better robustness, and consistency with nearly every > > other fd we track. >=20 > That socket needs to be blocking for the second usage we make of it in > tap_send_frames_passt(), that is, the one via write_remainder() without > MSG_DONTWAIT. Good point. I've dropped that change and adjusted the text to match. >=20 > While a part of https://bugs.passt.top/show_bug.cgi?id=3D38 is solved > (there are no blocking reads left in tap_passt_input()), this isn't the > case for the writing side of it. >=20 > Some nits below: >=20 > > Signed-off-by: David Gibson > > --- > > conf.c | 6 ++++++ > > repair.c | 4 ++++ > > tap.c | 3 ++- > > 3 files changed, 12 insertions(+), 1 deletion(-) > >=20 > > diff --git a/conf.c b/conf.c > > index dec43fca..dc85f0f8 100644 > > --- a/conf.c > > +++ b/conf.c > > @@ -2082,6 +2082,12 @@ static void conf_accept(struct ctx *c) > > int fd, rc; > > =20 > > retry: > > + /* Currently we perform the configuration transaction more-or-less > > + * synchronously, so we want the accepted socket to be blocking. > > + * > > + * FIXME: We should make the configuration update asynchronous, like > > + * most of our operation, so a misbehaving configuration client can't > > + * block the main forwarding loop */ >=20 > * ... loop. > */ >=20 > > fd =3D accept4(c->fd_control_listen, NULL, NULL, SOCK_CLOEXEC); > > if (fd < 0) { > > if (errno !=3D EAGAIN) > > diff --git a/repair.c b/repair.c > > index 42c4ae97..8a2d119d 100644 > > --- a/repair.c > > +++ b/repair.c > > @@ -99,6 +99,10 @@ int repair_listen_handler(struct ctx *c, uint32_t ev= ents) > > return EEXIST; > > } > > =20 > > + /* We want accepted socket to be blocking; we use it during migration >=20 > "the accepted socket" >=20 > > + * which is a synchronous interruption to our normal non-blocking > > + * behaviour. > > + */ > > if ((c->fd_repair =3D accept4(c->fd_repair_listen, NULL, NULL, > > SOCK_CLOEXEC)) < 0) { > > if ((rc =3D errno) !=3D EAGAIN) > > diff --git a/tap.c b/tap.c > > index fda2da9b..3b8a3f3d 100644 > > --- a/tap.c > > +++ b/tap.c > > @@ -1490,7 +1490,8 @@ void tap_listen_handler(struct ctx *c, uint32_t e= vents) > > return; > > } > > =20 > > - c->fd_tap =3D accept4(c->fd_tap_listen, NULL, NULL, SOCK_CLOEXEC); > > + c->fd_tap =3D accept4(c->fd_tap_listen, NULL, NULL, > > + SOCK_NONBLOCK | SOCK_CLOEXEC); >=20 > ...so this part would need to be dropped.=20 >=20 > > if (c->fd_tap < 0) { > > if (errno !=3D EAGAIN) > > warn_perror("Error accepting tap client"); >=20 > The rest looks good to me. >=20 > --=20 > Stefano >=20 --=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 --hvier0rT/H0S2TiO Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmoKflgACgkQzQJF27ox 2GcjzQ//QtgJ3dTFs6rJO/+wyOyvnloirt1iZQnzMBG6HsiaG2g4Y37ohYGZSfUB /7yc0jBk0515186rQwaP6E+lhCnn5kmrro8tROZKyDqP13s9QLYwAcTPffyrsb4a uLY0WE+gI2RopBoKvjoHGUrrzd/Kq3UZOVUHw2ECknbudvxXZ/V60XKOM09CMkzg Rjhb+lVc4FXSccluQmAvt59TWbbMwyBHKBKtRWpyjSvBHOqC111ATEHy/TD+NVDL d0tm7Frh85MOMC/3mAi/fkYNNo8PDcbGdHn4es6YDqR2XRBwaZX/yKot0G1/vK9c 51UWxcoD5oXcFx6aOF6SxkvsIXpPDa4RkPZcOMuNLCWzLb4xleQjaA2qh6WUuZS3 Bn/Yha115jJL4S3nqpoyNqY0j1PGksp/z/W4wfO1kVyiM93NH5E/WjfpGDKo4N7V y3RS2JOPjnoWb5vIwc4UMWjvAqGaLLkBmLZMAcWwJX2hiQ/sj8gnoAt9R9wYODSP S/efBbK+jRhKWCdYTu1bVaJIi5m4tUVTwm0cocOr5XAFaIH7amFK4jRckxR6J2qv gIBZMlZGQBovHd1ictA63nVMSeF0hgDYDwbJOCyyvcXjB4Gk76cxtagycdIl8qB7 QQM74E6abwsjGhyLU819m/lhQCy/sRm6NIADkV5M9k0vITQ74EI= =d5pC -----END PGP SIGNATURE----- --hvier0rT/H0S2TiO--