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.
Details
- Reviewers
markj - Group Reviewers
network transport - Commits
- rG315167c0de1a: unix: provide an option to return locked from unp_connectat()
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
sys/kern/uipc_usrreq.c | ||
---|---|---|
1997 | 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. |
sys/kern/uipc_usrreq.c | ||
---|---|---|
1997 | Thanks for input! I will put that into a comment. |
sys/kern/uipc_usrreq.c | ||
---|---|---|
1993 | So let's assert !(return_locked && connreq)? |
sys/kern/uipc_usrreq.c | ||
---|---|---|
1220 | 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. |
sys/kern/uipc_usrreq.c | ||
---|---|---|
1220 | I can't understand. The whole idea of this revision is that unp_connectat() doesn't drop the locks and such situation is impossible. |
sys/kern/uipc_usrreq.c | ||
---|---|---|
1220 | Ah, got it. |