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:
Mark Johnston 2023-09-27 08:24:11 -04:00
parent 015daf5221
commit 61a14ddfe0

View file

@ -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)