Re: unix_stream_connect and socket address resolution

On Wed, Jul 22, 2026 at 12:02:24PM -0400, John Ericson wrote:

Thanks Günther!

This example makes sense to me. The behavior still feels a little odd to
me, but I can understand the practical benefit of what you describe, and
also why changing it would definitely cause breakage.

I have one addendum to ask then which is: what if before the loop we
pre-resolve the parent directory as a concrete `struct path`, and then
on each iteration of the loop resolve only the final path component to
the socket itself? (That is a single-component lookup relative to the
pre-resolved parent, to be clear.)

I am not sure about that.  I think the difficult question here are the
ordering guarantees on file system operations:

The file system can be in a different state in the first and the second
half of the path walk, and I'm not sure whether that wouldn't violate
file system ordering guarantees.  If you intend to send such a patch,
I'd recommend to loop in some file system experts (e.g. Christian
Brauner).

What is the underlying problem that such a patch would solve though?
Do you think that the performance on retry is such a concern?
(After all, you'd also have to do a "split" lookup in the happy case,
and it sounds likely that that the retry improvement does not amortize
the happy path penalty?)

(This would have to be explained in the commit message as well, per [1])

[1] https://docs.kernel.org/process/submitting-patches.html#describe-your-changes

Per your example, a legitimate server restart recreates the socket inode
in the same directory, so this still picks up the new socket and
reconnects, while avoiding the effect where a concurrent
ancestor-directory rename causes a wildly different socket to be
resolved. Hopefully this preserves the intended use-case.

Note that this does mean recreating the parent directory itself at the
same path would no longer be followed, and a rename/unlink of the pinned
parent would cause the lookup to fail rather than resolve elsewhere.
That seems like the intended, safer direction to me, but flagging it as
a deliberate semantic change rather than an accident.

If this sounds like an acceptable middle-ground to everyone, I'd be happy to implement it.

—Günther