Re: [PATCH v8 10/19] pesto, conf: Have pesto connect to passt and check versions

[David Gibson <david@gibson.dropbear.id.au>]

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

On Wed, May 06, 2026 at 09:55:32AM +0200, Stefano Brivio wrote:
> On Wed, 6 May 2026 15:38:30 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Wed, May 06, 2026 at 01:47:10AM +0200, Stefano Brivio wrote:
> > > From: David Gibson <david@gibson.dropbear.id.au>
> > > 
> > > 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 <david@gibson.dropbear.id.au>
> > > [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:

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.
> 
> ...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.
> 
> 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 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.
> 
> > 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,

"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).
> 
> -- 
> Stefano
> 

-- 
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 --]