Re: unix_stream_connect and socket address resolution
From: Günther Noack <hidden>
Date: 2026-07-22 07:26:03
Also in:
linux-security-module, lkml
Hello John! On Tue, Jul 21, 2026 at 04:37:07PM -0400, John Ericson wrote:
quoted hunk ↗ jump to hunk
In case this is useful or interesting to anyone, I deep a some history spelunking, and the restart logic in question seems to date back to Import 2.2.4pre6: https://github.com/tbodt/linux-history/commit/7d4fc34b9bbc0a14d3e5f6b2f978373422e1ca8a#diff-0553d076c243e06ae312480cb8cb52f1cebe1d80fc099d3842593e12c9e0d4f3 ---@@ -673,9 +703,25 @@ static int unix_stream_connect(struct socket *sock, struct sockaddr *uaddr, we will have to recheck all again in any case. */ +restart: /* Find listening sock */ other=unix_find_other(sunaddr, addr_len, sk->type, hash, &err); + if (!other) + return -ECONNREFUSED; + + while (other->ack_backlog >= other->max_ack_backlog) { + unix_unlock(other); + if (other->dead || other->state != TCP_LISTEN) + return -ECONNREFUSED; + if (flags & O_NONBLOCK) + return -EAGAIN; + interruptible_sleep_on(&unix_ack_wqueue); + if (signal_pending(current)) + return -ERESTARTSYS; + goto restart; + } + /* create new sock for complete connection */ newsk = unix_create1(NULL, 1);@@ -704,7 +750,7 @@ static int unix_stream_connect(struct socket *sock, struct sockaddr *uaddr, /* Check that listener is in valid state. */ err = -ECONNREFUSED; - if (other == NULL || other->dead || other->state != TCP_LISTEN) + if (other->dead || other->state != TCP_LISTEN) goto out; err = -ENOMEM; ---My question can be basically restated: why should the `restart` label not go *after* the `unix_find_other` call?
To elaborate on David Laights answer -- the classic way of restarting a Unix Domain socket server is that the server unlink(2)s the socket file and then bind(2)s the address again. In other words, when the server restarts, the new instance offers the service on a socket file with the same name but it's technically a *fresh* socket file. So a "normal" server restart is not technically that different to the example you gave in your earlier mail (the "File system version"). Another variant of this is one where the server uses rename(2) to switch out the socket file atomically during restart. I was not around when that af_unix code was written, and cannot guarantee that by interpretation is correct, but in the hope that someone will point it out if it's totally bogus: My interpretation is that the "goto restart" loop in af_unix.c is designed to smoothen the server restart cases in a way so that the client doesn't have to deal with manual system call restarts. That loop needs to include the repeated vfs lookup so that it actually gets the socket that belongs to the fresh socket file. (Otherwise it would just observe the same SOCK_DEAD socket from the old server process again. - The new server serves from a new struct socket.) Example Scenario, where a client connect(2) races with the shutdown of an old server during an "atomic" (rename(2)) server restart: * Old server process serves on /foo/bar.sock * New server process starts up * New server process binds (and creates) /foo/bar.sock.tmp * Client runs connect(2) to /foo/bar.sock, does the unix_find_other lookup, getting the old server's socket * New server process renames /foo/bar.sock.tmp to /foo/bar.sock * Old server process shuts down, socket transitions to SOCK_DEAD through unix_release() -> unix_release_sock() -> sock_orphan() * Client connect(2) syscall checks the socket and discovers the SOCK_DEAD state, because it still holds a pointer to the old server socket. To recover from this, connect(2) does the VFS lookup again, because the already looked up dead socket isn't coming back. The connect(2) function pretends that it ran a tiny bit later and only observed the new socket. In this scenario, the userspace server is already going to great lengths to make the switch atomic - it would be surprising IMHO if the connect(2) operation could still return errors to userspace due to race conditions in that case. Again, this is just my own interpretation. I also did not find any better documentation on this. If I am wrong, I am more than happy to be corrected. :) –Günther