From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=TP+CHy6S; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 0C16F5A0265 for ; Wed, 06 May 2026 09:55:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1778054136; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QOks7YjVZEkPCD7dwV6KqrAcW1kep3WlFNxPy1246oQ=; b=TP+CHy6SJ5adXqbIFA9k5YwzbEx/O6t0uIdMdzBBY2CjRYj5JNhM/Kqs0XP6MJmbh7vL/F KO2DqZ0H+wDsX2nbHAfhHPypEsTg5TPCcGzvPNYDVRapSVA6sYgHL579Q85fIFrdRpFi4e CxNNwQ/vCynXRLBBcCxg3Am+NNwRsrs= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-322-zkf4aX_mPiWAVXfMGI6VIw-1; Wed, 06 May 2026 03:55:34 -0400 X-MC-Unique: zkf4aX_mPiWAVXfMGI6VIw-1 X-Mimecast-MFC-AGG-ID: zkf4aX_mPiWAVXfMGI6VIw_1778054133 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-44d79da8cf7so2531201f8f.2 for ; Wed, 06 May 2026 00:55:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778054133; x=1778658933; h=date:content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QOks7YjVZEkPCD7dwV6KqrAcW1kep3WlFNxPy1246oQ=; b=sPlhq+NN1Wlkvj6kS1UJRl2O+MYIR/oh4RXN97TO9J+c8nRbv2W2qOHCoz294kQHlD NNOKLKm23bnmcf+wafwfxj4NgLJwnADUIcWi5m7V9KF8etrQFLJmnxRD9CNtB+4mRuwo QmKbfOUtYByP/y8U9Hhiy48mTToKkoEi8laC8cCaIgpRjbxs0FJB4tJpjdnDpbLvaKFI 9q0PHMbAUfG0uLCqGwiMadzRFF97ed2Tq4fNmsoQxCD1k/k7fWQN84Evp252TSHJotoZ gBTd8MAufkvn2+M83eWl5F8mcAYRqlts/35BFOrmYXhUskcbZjtZLrgcTmLbrR3HI0nv FnyQ== X-Gm-Message-State: AOJu0YzwgESy4yO0lVbJNyhjwBtVzC7uVDSQBIQNTnlCdV3wTryflZ0Q WJ7s7xLtX0NQmE0Du7zmNtma85AhAZchzcMCIzTiGWyxGFECOzgKRF2QfJwhCtazbMDveJQc5gk +k2VQhQ8iJIcz8yR8XUpJHDLzBTNC7+9SOdmDAo7K6ZyNIrNXmSTMvQ== X-Gm-Gg: AeBDievg/LkNchwCBfcOiLGdxGx/q2QLwUtX4/Wv7M8weMspA7Qnnl7IO0ltYnWDwUM +s9pcJ/pEC2vYJSk1dCSbt/zTHSLvxKUdgkgXAnatxO9faok3tpbqRBCO+XdYKGxHEtbKNlHA6B vhQjXo7qwPiQdaLi8Zf1u5NR2r1HXt+37lrbPjvpg53ZWhD71elGaiIMppMLLdc1iY+YIc1G4tY W6owwE1EHTUj/uSCqed7b5tieaYDURVwFi9/WcGccBAsq3Ma/m9h8IfAxbrgttLxTXMVmB49NNI t/sABgFC78Gh2/5+qhy+CIXWqAp7zbkXjTMBm+E98aJriXym0kEWI+BFH6+dbgIXktjcCcF2ePP ZTWymnDiInf1c2JkpzNDb/FdyTsJLCGxZPmY0HIf+Ebw= X-Received: by 2002:a05:6000:1a85:b0:43d:26a2:f8c3 with SMTP id ffacd0b85a97d-4515d3dca3cmr3665361f8f.35.1778054133470; Wed, 06 May 2026 00:55:33 -0700 (PDT) X-Received: by 2002:a05:6000:1a85:b0:43d:26a2:f8c3 with SMTP id ffacd0b85a97d-4515d3dca3cmr3665320f8f.35.1778054132918; Wed, 06 May 2026 00:55:32 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4505558e213sm11075499f8f.25.2026.05.06.00.55.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 May 2026 00:55:32 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v8 10/19] pesto, conf: Have pesto connect to passt and check versions Message-ID: <20260506095531.0b1387c5@elisabeth> In-Reply-To: References: <20260505234719.1437340-1-sbrivio@redhat.com> <20260505234719.1437340-11-sbrivio@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Wed, 06 May 2026 09:55:32 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: ID-0SP9Mn3Ndu7VJuBoPMSgY58FSJqqrI7DcI8Br8T0_1778054133 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: LXQTCFZYS7JNNWSHIOWFSTSTIAWXZFYP X-Message-ID-Hash: LXQTCFZYS7JNNWSHIOWFSTSTIAWXZFYP X-MailFrom: sbrivio@redhat.com 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: On Wed, 6 May 2026 15:38:30 +1000 David Gibson wrote: > On Wed, May 06, 2026 at 01:47:10AM +0200, Stefano Brivio wrote: > > From: David Gibson > > > > Start implementing pesto in earnest. Create a control/configuration > > socket in passt. Have pesto connect to it and retrieve a server greeting > > Perform some basic version checking. > > > > Signed-off-by: David Gibson > > [sbrivio: Avoid potential recursive calling between conf_accept() and > > conf_close(), reported by clang-tidy] > > 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. > > > [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()] > > 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"). Oops, now that Laurent mentioned it, I realised I dropped it accidentally while / after debugging things on v6, and: > 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. ...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. I don't remember if this was while testing things on Fedora or Debian, it only happened in one of the two environments. 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: - O_NONBLOCK on the accepted socket breaks things - 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 Without that patch, and my follow-up change to this patch, we're just adding two lines for this specific behaviour, instead of 18. > We will want non-blocking it when we change this to read out the > updated rules incrementally, rather than all at once. Right, so maybe we can keep that patch for that moment. Or even before, 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). -- Stefano