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
- rS FreeBSD src repository - subversion
- Lint
Lint Warnings Severity Location Code Message Warning sys/kern/uipc_usrreq.c:724 SPELL1 Possible Spelling Mistake Warning sys/kern/uipc_usrreq.c:1823 SPELL1 Possible Spelling Mistake - Unit
No Test Coverage - Build Status
Buildable 45714 Build 42602: arc lint + arc unit
Event Timeline
sys/kern/uipc_usrreq.c | ||
---|---|---|
1989 | 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 | ||
---|---|---|
1989 | Thanks for input! I will put that into a comment. |
sys/kern/uipc_usrreq.c | ||
---|---|---|
1987 | So let's assert !(return_locked && connreq)? |
sys/kern/uipc_usrreq.c | ||
---|---|---|
1216 | 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 | ||
---|---|---|
1216 | 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 | ||
---|---|---|
1216 | Ah, got it. |