Re: unix_stream_connect and socket address resolution

[Günther Noack]

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