Re: [PATCH v2 3/3] conf, repair, tap: Document reasons for blocking Unix sockets

On Wed, May 20, 2026 at 02:52:14AM +0200, Stefano Brivio wrote:

On Mon, 18 May 2026 13:22:43 +1000 David Gibson wrote:

...

Most of our operation is asynchronous, based on non-blocking fds handled in our epoll loop. However, our several Unix sockets (tap client, repair helper, control client) are all blocking fds after accept().

That is in fact correct, but for not especially obvious reasons that are slightly different in each case. Add explanatory comments to each of them.

Signed-off-by: David Gibson --- conf.c | 6 ++++++ repair.c | 4 ++++ tap.c | 5 +++++ 3 files changed, 15 insertions(+)

diff --git a/conf.c b/conf.c index 029b9c7c..5c7dfea1 100644 --- a/conf.c +++ b/conf.c @@ -2084,6 +2084,12 @@ static void conf_accept(struct ctx *c) int fd, rc;

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. */

Nit I fixed on merge:

* [...] loop. */

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