unix: provide an option to return locked from unp_connectat()

[glebius]

Summary

Use this new version in unix/dgram socket when sending to a target
address. This removes extra lock release/acquisition and possible
counter-intuitive ENOTCONN.

[glebius]

Note: this patch is a step towards D35303.

[markj]

sys/kern/uipc_usrreq.c

1830

I don't have a concrete suggestion right now, but I don't like these kinds of "naked" boolean flags. IMO it'd be better to have a separate function.

1980

1986

vput() can sleep when releasing the final reference, so we can't hold PCB locks here.

[markj]

sys/kern/uipc_usrreq.c

1986

Thinking a bit more, unp2 should already hold a use-ref on the vnode, and this ref is protected by the PCB lock. So after the VOP_UNP_CONNECT() call I believe the use count on vp will be >= 2. The problem is that unp2's PCB lock is released after calling sonewconn(), and after that point the use count can drop to 1. But in the !connreq case (i.e., the SOCK_DGRAM case), I think the vput() call is effectively guaranteed not to sleep. Not sure if that's sufficient for you.

[glebius]

sys/kern/uipc_usrreq.c

1986

Thanks for input! I will put that into a comment.

[glebius]

Add comment. Rebase.

[markj]

sys/kern/uipc_usrreq.c

1989

So let's assert !(return_locked && connreq)?

[glebius]

Add assertion befor vput().

[markj]

sys/kern/uipc_usrreq.c

1222

Instead use unp2 = unp_pcb_lock_peer(unp) and check for NULL. I believe it is possible for the socket to be disconnected again while PCB locks are dropped.

[glebius]

sys/kern/uipc_usrreq.c

1222

I can't understand. The whole idea of this revision is that unp_connectat() doesn't drop the locks and such situation is impossible.

[markj]

sys/kern/uipc_usrreq.c

1222

Ah, got it.