mirror of
https://github.com/freebsd/freebsd-src
synced 2024-10-15 21:05:08 +00:00
unix: Fix a lock order reveral
Running the test suite yields: lock order reversal: 1st 0xfffff80004bc6700 unp (unp, sleep mutex) @ sys/kern/uipc_usrreq.c:390 2nd 0xffffffff81a94b30 unp_link_rwlock (unp_link_rwlock, rw) @ sys/kern/uipc_usrreq.c:2934 lock order unp -> unp_link_rwlock attempted at: 0xffffffff80bc216e at witness_checkorder+0xbbe 0xffffffff80b493a5 at _rw_wlock_cookie+0x65 0xffffffff80c0a8e2 at unp_discard+0x22 0xffffffff80c0a888 at unp_freerights+0x38 0xffffffff80c09fdd at unp_scan+0x9d 0xffffffff80c0f9a7 at uipc_sosend_dgram+0x727 0xffffffff80c00a79 at sousrsend+0x79 0xffffffff80c072d0 at kern_sendit+0x1c0 0xffffffff80c074d7 at sendit+0xb7 0xffffffff80c076f3 at sys_sendmsg+0x63 0xffffffff8104d957 at amd64_syscall+0x6b7 0xffffffff8101f9eb at fast_syscall_common+0xf8 This happens when uipc_sosend_dgram() discards a control message because the receive socket buffer is full. The overflow handling frees internalized file references in the socket buffer before freeing mbufs. It does this with socket PCBs locked, leading to the LOR. Defer handling of file references until the PCBs are unlocked. Reviewed by: glebius MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D41884
This commit is contained in:
parent
015daf5221
commit
61a14ddfe0
|
@ -1332,8 +1332,10 @@ uipc_sosend_dgram(struct socket *so, struct sockaddr *addr, struct uio *uio,
|
|||
} else {
|
||||
soroverflow_locked(so2);
|
||||
error = ENOBUFS;
|
||||
if (f->m_next->m_type == MT_CONTROL)
|
||||
unp_scan(f->m_next, unp_freerights);
|
||||
if (f->m_next->m_type == MT_CONTROL) {
|
||||
c = f->m_next;
|
||||
f->m_next = NULL;
|
||||
}
|
||||
}
|
||||
|
||||
if (addr != NULL)
|
||||
|
|
Loading…
Reference in a new issue