With this second step PF_UNIX/SOCK_DGRAM has protocol specific
implementation. This gives some possibility performance
optimizations. However, it still operates on the same struct
socket as all other sockets do.
Details
Details
- Reviewers
markj - Group Reviewers
network transport - Commits
- rGe3fbbf965e94: unix/dgram: add a specific receive method - uipc_soreceive_dgram
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 45708 Build 42596: arc lint + arc unit
Event Timeline
sys/kern/uipc_usrreq.c | ||
---|---|---|
1286 | Yes, and this is the intent. Before we did the same in soreceive_generic() uipc_socket.c:2159 | |
1441 | Good catch! In the soreceive_generic() we catch the error much later and my code doesn't have it. I'm looking in making unp_externalize() to never fail, at least for SOCK_DGRAM. |
sys/kern/uipc_usrreq.c | ||
---|---|---|
1430 | ||
1431 | Related, unp_scan() will visit m->m_nextpkt, since it was intended to operate on the entire socket buffer. I can't find any problems caused by that, but it seems rather subtle. Might be worth asserting m->m_nextpkt == NULL before calling unp_scan() below and elsewhere in your patch set. Or improve the KPI to remove such footguns. |