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=jm5QR33D; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 50C885A0265 for ; Wed, 06 May 2026 10:21:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202602; t=1778055697; bh=DdXIqZroRyTd8Tib4yuK2lXTdI8+kU3RBHYU0wjTBbI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jm5QR33Ds6Nm0kv6F5uW/uLUwWugzD8gZYCouTipqZN/onIT8BFsBlXzK9FbAxyW/ VUJlzZ3d+72I5AvuSWE05F4okGRt3hCW0Npa6J/frIn7cf1P6NhmHlbzRi6fl6OCKK w250SFnlHxMcNf/BcwzU0LoPkrSvLza3qCr5m1G3QR7So/Fb3cJDhfovYqtqn2AMCE HI/486DPoe/ghyFcW8e4RHjYXzECl6VIDhAsDQJ87Hue/otIdh9nu5AAfuM70CWPHr 6wUu/VMlVR6WTJf2Q2n6pJshyGQvH0nWGfOJWTBQUuCJg+6dSlTj2eip/hPUmyEZE0 DRYKt9iq3diVQ== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4g9Syn07rBz4wJK; Wed, 06 May 2026 18:21:37 +1000 (AEST) Date: Wed, 6 May 2026 18:21:32 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v8 10/19] pesto, conf: Have pesto connect to passt and check versions Message-ID: References: <20260505234719.1437340-1-sbrivio@redhat.com> <20260505234719.1437340-11-sbrivio@redhat.com> <20260506095531.0b1387c5@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iQZ/japD5Ukxuibu" Content-Disposition: inline In-Reply-To: <20260506095531.0b1387c5@elisabeth> Message-ID-Hash: PDUHQDR242B2R4IQZC6QURTPDFMCXEOY X-Message-ID-Hash: PDUHQDR242B2R4IQZC6QURTPDFMCXEOY 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, Jon Maloy , Laurent Vivier 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: --iQZ/japD5Ukxuibu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 06, 2026 at 09:55:32AM +0200, Stefano Brivio wrote: > On Wed, 6 May 2026 15:38:30 +1000 > David Gibson wrote: >=20 > > On Wed, May 06, 2026 at 01:47:10AM +0200, Stefano Brivio wrote: > > > From: David Gibson > > >=20 > > > Start implementing pesto in earnest. Create a control/configuration > > > socket in passt. Have pesto connect to it and retrieve a server gree= ting > > > Perform some basic version checking. > > >=20 > > > Signed-off-by: David Gibson > > > [sbrivio: Avoid potential recursive calling between conf_accept() and > > > conf_close(), reported by clang-tidy] =20 > >=20 > > Huh. For some reason that warning didn't trip for me. Although it's > > technically true they can mutually recurse, I believe they're both > > tail calls, so it shouldn't eat the stack. > >=20 > > > [sbrivio: In conf(), check we're not exceeding sizeof(c->control_path) > > > instead of sizeof(c->socket_path), and, in pesto's main(), print > > > argv[optind] instead of argv[1] to indicate an invalid socket path, > > > both reported by Jon Maloy] > > > [sbrivio: In pesto's main(), drop unnecessary newline from error > > > message, reported by Laurent] > > > [sbrivio: Don't use SOCK_NONBLOCK on accept4(), as that only applies > > > to the *new* file descriptor, which we don't want -- set O_NONBLOCK > > > on the listening file descriptor using fcntl()] =20 > >=20 > > Making the new (accepted) socket non-blocking was the intended > > behaviour here. We also want non-blocking for the listening socket, > > but that was already done in feab892c7 ("tap, repair: Use > > SOCK_NONBLOCK and SOCK_CLOEXEC on Unix sockets"). >=20 > Oops, now that Laurent mentioned it, I realised I dropped it > accidentally while / after debugging things on v6, and: Ah, right. > > WIth the current design, I guess we don't want non-blocking on the > > accepted socket, although I don't think it actually matters very much. >=20 > ...this is the issue I was trying to fix: if the accepted socket is > non-blocking, messages are cut short sometimes, and in general things > don't work. Hrm. I was pretty sure setting it blocking just meant you'd always get *some* data instead of EAGAIN. I don't believe it prevents either short reads or short writes. Both sides should already be using {read,write}_all_buf() to handle short read/writes, so I'm really not sure where it's going wrong if the accepted socket is non-blocking (other than maybe spinning on EAGAIN more than we'd like). > I don't remember if this was while testing things on Fedora or Debian, > it only happened in one of the two environments. >=20 > So, while it was accidental (I really didn't leave any note for a cover > letter, so I'm almost certain there was no other reason for me to drop > it), I think it's actually a good idea to drop it for the following > reasons: >=20 > - O_NONBLOCK on the accepted socket breaks things The earlier patch doesn't affect O_NONBLOCK on the accepted socket, only on the listening socket (it's not inherited). > - the rest looks correct to me but fairly out of scope, and I have very > limited time for testing things in detail right now, so I'd rather > keep that patch for later It's in scope because O_NONBLOCK on the listening socket is essential to implementing the "concurrent client blocks" instead of "concurrent client is rejected" behaviour. Without O_NONBLOCK on the listening socket, we can't safely call conf_accept() anywhere other than in response to the epoll event - because looking for additional connections after we close one could block. > Without that patch, and my follow-up change to this patch, we're just > adding two lines for this specific behaviour, instead of 18. >=20 > > We will want non-blocking it when we change this to read out the > > updated rules incrementally, rather than all at once. >=20 > Right, so maybe we can keep that patch for that moment. Or even > before, "that patch" meaning the sock_unix() one? Again, that affects the listening socket behaviour. What we need for incrementally reading the rules is about the accepted socket behaviour. > again, I think it's all correct and desirable, just out of scope (this > isn't the reason why I dropped it though, I would have written a note). >=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 --iQZ/japD5Ukxuibu Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmn6+f8ACgkQzQJF27ox 2GeHlg//VcwLat/CiJC7k7BLl04LilkQrjBMB0A7CN1+KBxDjN+1yCRMdBNnNRXQ TdMR0BQ/SAHUIYGDtyxJdxqBAG5EAIvoJnlO3gTdLuTqF10nYPhktYCGugomJdCb U5vlLYw3gQkhUJJPbD89+DsbvTnQGLGd7Tj0nlUrwZhal10zq4OeZjKXMtCcpZ1O xbIEyPOZWfzMv/RxlSZCI9S3FHKORnLQmXtR2IvJpjsj3X14xqNK37glFjVcDc6d 47YQ9DJo0R4oTg6DRLSCLfVV59h4SUupzeaERmfazu8ZVzTdRh9aJ5zByPi9vjtJ DjhtrTZw4ayyxhWDgVFuaD13XYdInwjt2so/Ep/4wODIE8FLQf0ZHg2e1nNafLX4 AGtZheyvbKww85HK/uWWgXzYj668e9zFK7bvEsQuzRhAZBrtRctARPN9MO8KVpth QFa14EHvBXdpzDxTjOr/jWDshqkwhKSm2YzangQgZBm/Nh9wQ80NHkkIwl3FMhCf 6Np5KgRnki5qy6uhjvGS53mDH6MrQzwL6w3PpzVL14dz63mkWLvFv0UhmZrlorXo am0ZXXOERPM8uJMZV6HwTbnDeBsX3Drtu6gPHF9xk1ffC9BlifUfvrXYhIFAcKGt JqXI0TjyGh7alz0+PgFEF1MoXjD02P2iZPrvRmyfWdVW1DJ/d6o= =r28i -----END PGP SIGNATURE----- --iQZ/japD5Ukxuibu--