unix: split `unp_connectat()` in two

[inquire_JohnEricson.me]

Summary

Factor the second half — connecting to an already-resolved peer PCB —
out into a new unp_connect_peer(), leaving unp_connectat() with the
connection state machine and pathname resolution. No functional change.

The helper's contract: the caller guarantees stability of the peer PCB
(vnode lock plus unp_vp_mtxpool lock for peers found via
VOP_UNP_CONNECT()), has set UNP_CONNECTING on the connecting socket,
and clears it again on error; the helper clears it on success.

This prepares for connecting to a peer named by something other than a
pathname.

Signed-off-by: John Ericson <[e-mail]>

[markj]

Looks good to me overall.

sys/kern/uipc_usrreq.c

3003

If you write this fragment like this:

if (unp2 == NULL)
    error = ECONNREFUSED;
else
    error = unp_connect_peer(so, unp2, &sa, td, return_locked);
mtx_unlock(vplock);

then you don't need the bad2 label.

[inquire_JohnEricson.me]

Rework error handling to avoid "bad2" as requested

[inquire_JohnEricson.me]

OK thanks for approving! To be clear, I don't think I have permissions to land it (not really sure how arcanist intended contributors to do this part). Will one of you land it either now, or once we've approved the whole stack?

[markj]

In D58404#1340667, @inquire_JohnEricson.me wrote:

OK thanks for approving! To be clear, I don't think I have permissions to land it (not really sure how arcanist intended contributors to do this part). Will one of you land it either now, or once we've approved the whole stack?

Yeah, at this point it's up to someone with commit access to actually land the patch and push to git.

I think it's ok to land this as a standalone cleanup, but it'd be nice to conclude the discussion on D58405 first. (If you want to have a broader discussion of the proposal, starting a thread on the freebsd-hackers@ or freebsd-arch@ mailing lists would be the way to go.)

[inquire_JohnEricson.me]

Sure, that sounds good to me. I just wanted to double-check the process. I am happy to continue discussing on D58405, and don't see a need to create a broader mailing list thread if we end up just on Phabricator with you two happy to approve it.

(BTW concurrently to this patch series, I am also working on what I proposed long ago in https://lists.freebsd.org/archives/freebsd-arch/2022-January/000140.html. That is far more involved, and so I think it *does* merit mailing list discussion, but I'll refrain from sending another email until I have a complete draft.)