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=FJbhAWwU; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id C2FD85A0265 for ; Mon, 18 May 2026 05:22:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202602; t=1779074566; bh=tFet51yCFZVYk1h/rNY8ezMS7+S9R/rhIExdnCSkHbw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FJbhAWwUk2svKvgrq11cJfOAGzhK+/mo/+wgZ/4zMwrCGZuymvCBeN2LXCk/Jpu2F ELyxwmFb4bnlGQI7UVWglZodSxHJ97C2sJ7syzmELYXBkm3gP2P9wm9aSxZch/5zVE WTy4bA4bP3BQZSVhM4yFJudV//IN/5/ho3FjrOwD5056LY1el5wXzxDFV95+am9O59 O9SJrjZkhwKeyu8Wxvd3hWpB5f+RLy/4F/Qx9QJQn+q30T7kxMSr+nWw/sWFp2phIS peb2J1+fDUDmUE3xvuPJrqdxcLA5Y8jdCaK02+fHfOqlFB8ILFhO3oaQsaK1C3m5Nb nVZPEpI6mcc3w== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4gJjmQ46lBz4wTT; Mon, 18 May 2026 13:22:46 +1000 (AEST) From: David Gibson To: passt-dev@passt.top, Stefano Brivio Subject: [PATCH v2 3/3] conf, repair, tap: Document reasons for blocking Unix sockets Date: Mon, 18 May 2026 13:22:43 +1000 Message-ID: <20260518032243.823768-4-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260518032243.823768-1-david@gibson.dropbear.id.au> References: <20260518032243.823768-1-david@gibson.dropbear.id.au> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID-Hash: RTWDE6DLEWIUTQKRPJ6XYH5OZRAHZT62 X-Message-ID-Hash: RTWDE6DLEWIUTQKRPJ6XYH5OZRAHZT62 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: David Gibson 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: 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. */ fd = accept4(c->fd_control_listen, NULL, NULL, SOCK_CLOEXEC); if (fd < 0) { if (errno != EAGAIN) diff --git a/repair.c b/repair.c index 3e0e3e0a..f31cccee 100644 --- a/repair.c +++ b/repair.c @@ -99,6 +99,10 @@ int repair_listen_handler(struct ctx *c, uint32_t events) return EEXIST; } + /* We want the accepted socket to be blocking; we use it during + * migration which is a synchronous interruption to our normal + * non-blocking behaviour. + */ if ((c->fd_repair = accept4(c->fd_repair_listen, NULL, NULL, SOCK_CLOEXEC)) < 0) { rc = errno; diff --git a/tap.c b/tap.c index 660f1cb6..d73068e5 100644 --- a/tap.c +++ b/tap.c @@ -1490,6 +1490,11 @@ void tap_listen_handler(struct ctx *c, uint32_t events) return; } + /* Because we generally only access the accepted socket from epoll + * events, it usually doesn't matter if it's blocking or non-blocking. + * However, in rare cases when the socket buffer fills we need (briefly, + * we hope) blocking writes (write_remainder() in send_frames_passt()). + */ c->fd_tap = accept4(c->fd_tap_listen, NULL, NULL, SOCK_CLOEXEC); if (c->fd_tap < 0) { warn_perror("Error accepting tap client"); -- 2.54.0