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

[Stefano Brivio <sbrivio@redhat.com>]

On Mon, 18 May 2026 13:22:43 +1000
David Gibson <david@gibson.dropbear.id.au> 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 <david@gibson.dropbear.id.au>
> ---
>  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.
	*/

-- 
Stefano