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 3/3] conf, repair, tap: More caution about blocking flag on Unix sockets
Date: Wed, 13 May 2026 14:14:23 +1000 [thread overview]
Message-ID: <20260513041423.2446716-4-david@gibson.dropbear.id.au> (raw)
In-Reply-To: <20260513041423.2446716-1-david@gibson.dropbear.id.au>
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's correct for the repair helper, and (for now) correct for the control
client. However, the reasons for that might not be obvious, so add some
extra comments giving the rationale.
I don't believe it's correct for the tap client; having this socket be
blocking means we could potentially block the main loop if we ever got a
a spurious EPOLL{IN,OUT} event on the tap socket. Switch the tap socket
to non-blocking for better robustness, and consistency with nearly every
other fd we track.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
conf.c | 6 ++++++
repair.c | 4 ++++
tap.c | 3 ++-
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/conf.c b/conf.c
index dec43fca..dc85f0f8 100644
--- a/conf.c
+++ b/conf.c
@@ -2082,6 +2082,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 42c4ae97..8a2d119d 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 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) {
if ((rc = errno) != EAGAIN)
diff --git a/tap.c b/tap.c
index fda2da9b..3b8a3f3d 100644
--- a/tap.c
+++ b/tap.c
@@ -1490,7 +1490,8 @@ void tap_listen_handler(struct ctx *c, uint32_t events)
return;
}
- c->fd_tap = accept4(c->fd_tap_listen, NULL, NULL, SOCK_CLOEXEC);
+ c->fd_tap = accept4(c->fd_tap_listen, NULL, NULL,
+ SOCK_NONBLOCK | SOCK_CLOEXEC);
if (c->fd_tap < 0) {
if (errno != EAGAIN)
warn_perror("Error accepting tap client");
--
2.54.0
prev parent reply other threads:[~2026-05-13 4:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-13 4:14 [PATCH 0/3] More caution with NONBLOCK " David Gibson
2026-05-13 4:14 ` [PATCH 1/3] treewide: Add SOCK_CLOEXEC to accept() calls that are missing it David Gibson
2026-05-13 4:14 ` [PATCH 2/3] conf, tap, repair: Uniformly use non-blocking accept() on Unix sockets David Gibson
2026-05-13 5:51 ` David Gibson
2026-05-13 4:14 ` David Gibson [this message]
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=20260513041423.2446716-4-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).