Skip to content

Commit b64ef53

Browse files
dgibsonsbrivio-rh
authored andcommitted
conf, repair, tap: Document reasons for blocking Unix sockets
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> [sbrivio: Fixed minor coding style detail in comment in conf_accept()] Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
1 parent 5ef0fc4 commit b64ef53

3 files changed

Lines changed: 16 additions & 0 deletions

File tree

conf.c

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2084,6 +2084,13 @@ static void conf_accept(struct ctx *c)
20842084
int fd, rc;
20852085

20862086
retry:
2087+
/* Currently we perform the configuration transaction more-or-less
2088+
* synchronously, so we want the accepted socket to be blocking.
2089+
*
2090+
* FIXME: We should make the configuration update asynchronous, like
2091+
* most of our operation, so a misbehaving configuration client can't
2092+
* block the main forwarding loop.
2093+
*/
20872094
fd = accept4(c->fd_control_listen, NULL, NULL, SOCK_CLOEXEC);
20882095
if (fd < 0) {
20892096
if (errno != EAGAIN)

repair.c

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -99,6 +99,10 @@ int repair_listen_handler(struct ctx *c, uint32_t events)
9999
return EEXIST;
100100
}
101101

102+
/* We want the accepted socket to be blocking; we use it during
103+
* migration which is a synchronous interruption to our normal
104+
* non-blocking behaviour.
105+
*/
102106
if ((c->fd_repair = accept4(c->fd_repair_listen, NULL, NULL,
103107
SOCK_CLOEXEC)) < 0) {
104108
rc = errno;

tap.c

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1492,6 +1492,11 @@ void tap_listen_handler(struct ctx *c, uint32_t events)
14921492
return;
14931493
}
14941494

1495+
/* Because we generally only access the accepted socket from epoll
1496+
* events, it usually doesn't matter if it's blocking or non-blocking.
1497+
* However, in rare cases when the socket buffer fills we need (briefly,
1498+
* we hope) blocking writes (write_remainder() in send_frames_passt()).
1499+
*/
14951500
c->fd_tap = accept4(c->fd_tap_listen, NULL, NULL, SOCK_CLOEXEC);
14961501
if (c->fd_tap < 0) {
14971502
warn_perror("Error accepting tap client");

0 commit comments

Comments
 (0)