From: David Gibson <david@gibson.dropbear.id.au>
To: Stefano Brivio <sbrivio@redhat.com>, passt-dev@passt.top
Cc: David Gibson <david@gibson.dropbear.id.au>
Subject: [PATCH v5 08/18] tap, repair: Use SOCK_NONBLOCK and SOCK_CLOEXEC on Unix sockets
Date: Tue, 21 Apr 2026 16:25:06 +1000 [thread overview]
Message-ID: <20260421062516.2601204-9-david@gibson.dropbear.id.au> (raw)
In-Reply-To: <20260421062516.2601204-1-david@gibson.dropbear.id.au>
sock_unix(), which creates a listening Unix socket, doesn't set the
SOCK_NONBLOCK flag. Generally, this doesn't matter because we only
accept() once we've received an epoll event awaiting a connection. However
we will need non-blocking accept() for the upcoming control/configuration
socket. Always add SOCK_NONBLOCK, which is more robust and in keeping with
the normal non-blocking style of passt.
In tap.c, always set SOCK_NONBLOCK and SOCK_CLOEXEC on the accept()ed
sockets as well, which we weren't doing in all cases before. According to
accept(2), in Linux accepted sockets do *not* inherit these flags from the
listening socket. Also check for failures of accept, discarding EAGAIN
silently (a spurious epoll event) and warning for other errors.
In repair.c, similarly always add CLOEXEC. Use NONBLOCK for discard
sockets, but *not* for the final repair socket, since we want blocking
transactions during migration.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
repair.c | 9 +++++++--
tap.c | 12 ++++++++++--
util.c | 2 +-
3 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/repair.c b/repair.c
index 69c53077..6c338da6 100644
--- a/repair.c
+++ b/repair.c
@@ -87,7 +87,7 @@ int repair_listen_handler(struct ctx *c, uint32_t events)
/* Another client is already connected: accept and close right away. */
if (c->fd_repair != -1) {
int discard = accept4(c->fd_repair_listen, NULL, NULL,
- SOCK_NONBLOCK);
+ SOCK_CLOEXEC | SOCK_NONBLOCK);
if (discard == -1)
return errno;
@@ -99,7 +99,12 @@ int repair_listen_handler(struct ctx *c, uint32_t events)
return EEXIST;
}
- if ((c->fd_repair = accept4(c->fd_repair_listen, NULL, NULL, 0)) < 0) {
+ /* We deliberately *don't* set SOCK_NONBLOCK on the accepted socket,
+ * because repair transactions happen during migration, when everything
+ * is blocked anyway.
+ */
+ if ((c->fd_repair = accept4(c->fd_repair_listen, NULL, NULL,
+ SOCK_CLOEXEC)) < 0) {
rc = errno;
debug_perror("accept4() on TCP_REPAIR helper listening socket");
return rc;
diff --git a/tap.c b/tap.c
index 7d06189d..87acd531 100644
--- a/tap.c
+++ b/tap.c
@@ -1415,7 +1415,7 @@ void tap_listen_handler(struct ctx *c, uint32_t events)
/* Another client is already connected: accept and close right away. */
if (c->fd_tap != -1) {
int discard = accept4(c->fd_tap_listen, NULL, NULL,
- SOCK_NONBLOCK);
+ SOCK_NONBLOCK | SOCK_CLOEXEC);
if (discard == -1)
return;
@@ -1428,7 +1428,15 @@ void tap_listen_handler(struct ctx *c, uint32_t events)
return;
}
- c->fd_tap = accept4(c->fd_tap_listen, NULL, NULL, 0);
+ c->fd_tap = accept4(c->fd_tap_listen, NULL, NULL,
+ SOCK_NONBLOCK | SOCK_CLOEXEC);
+ if (c->fd_tap == -1) {
+ /* EAGAIN means a harmless spurious event */
+ if (errno != EAGAIN) {
+ warn_perror("Unable to accept tap client");
+ }
+ return;
+ }
if (!getsockopt(c->fd_tap, SOL_SOCKET, SO_PEERCRED, &ucred, &len))
info("accepted connection from PID %i", ucred.pid);
diff --git a/util.c b/util.c
index 73c9d51d..204391c7 100644
--- a/util.c
+++ b/util.c
@@ -238,7 +238,7 @@ int sock_l4_dualstack_any(const struct ctx *c, enum epoll_type type,
*/
int sock_unix(char *sock_path)
{
- int fd = socket(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0);
+ int fd = socket(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK, 0);
struct sockaddr_un addr = {
.sun_family = AF_UNIX,
};
--
2.53.0
next prev parent reply other threads:[~2026-04-21 6:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-21 6:24 [PATCH v5 00/18] RFC: Dynamic configuration update implementation David Gibson
2026-04-21 6:24 ` [PATCH v5 01/18] conf, fwd: Stricter rule checking in fwd_rule_add() David Gibson
2026-04-21 6:25 ` [PATCH v5 02/18] fwd_rule: Move ephemeral port probing to fwd_rule.c David Gibson
2026-04-21 6:25 ` [PATCH v5 03/18] fwd, conf: Move rule parsing code to fwd_rule.[ch] David Gibson
2026-04-21 6:25 ` [PATCH v5 04/18] fwd_rule: Move conflict checking back within fwd_rule_add() David Gibson
2026-04-21 6:25 ` [PATCH v5 05/18] fwd: Generalise fwd_rules_info() David Gibson
2026-04-21 6:25 ` [PATCH v5 06/18] pif: Limit pif names to 128 bytes David Gibson
2026-04-21 6:25 ` [PATCH v5 07/18] fwd_rule: Fix some format specifiers David Gibson
2026-04-21 6:25 ` David Gibson [this message]
2026-04-21 6:25 ` [PATCH v5 09/18] pesto: Introduce stub configuration tool David Gibson
2026-04-21 6:25 ` [PATCH v5 10/18] pesto, log: Share log.h (but not log.c) with pesto tool David Gibson
2026-04-21 6:25 ` [PATCH v5 11/18] pesto, conf: Have pesto connect to passt and check versions David Gibson
2026-04-21 6:25 ` [PATCH v5 12/18] pesto: Expose list of pifs to pesto and optionally display David Gibson
2026-04-21 6:25 ` [PATCH v5 13/18] ip: Prepare ip.[ch] for sharing with pesto tool David Gibson
2026-04-21 6:25 ` [PATCH v5 14/18] inany: Prepare inany.[ch] " David Gibson
2026-04-21 6:25 ` [PATCH v5 15/18] pesto: Read current ruleset from passt/pasta and optionally display it David Gibson
2026-04-21 6:25 ` [PATCH v5 16/18] pesto: Parse and add new rules from command line David Gibson
2026-04-21 6:25 ` [PATCH v5 17/18] pesto, conf: Send updated rules from pesto back to passt/pasta David Gibson
2026-04-21 6:25 ` [PATCH v5 18/18] conf, fwd: Allow switching to new rules received from pesto David Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260421062516.2601204-9-david@gibson.dropbear.id.au \
--to=david@gibson.dropbear.id.au \
--cc=passt-dev@passt.top \
--cc=sbrivio@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://passt.top/passt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).