In uipc_usrreq(), when sending on a SOCK_DGRAM socket, I see the
following (taken from uipc_usrreq.c 1.53):

		if (control && (error = unp_internalize(control, p)))
			break;
		switch (so->so_type) {

		case SOCK_DGRAM: {
			if (nam) {
				if ((so->so_state & SS_ISCONNECTED) != 0) {
					error = EISCONN;
					goto die;
				}
				error = unp_connect(so, nam, p);
				if (error) {
				die:
					m_freem(control);
					m_freem(m);
					break;
				}
			} else {
				if ((so->so_state & SS_ISCONNECTED) == 0) {
					error = ENOTCONN;
					goto die;
				}
			}
			error = unp_output(m, control, unp, p);

This looks to me as though there's potential for a file table leak: if
the send fails for EISCONN or ENOTCONN reasons, or because
unp_connect() fails, then unp_internalize will have converted the file
descriptors into open file references, complete with incrementing the
f_count and f_msgcount values - but then the mbuf holding the
references is unceremoniously m_freem()ed, there will never be any
corresponding decrements, and the open file table entry(ies) in
question will stick around until reboot.

Am I hallucinating, or is this a bug?  Should I send it pr?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B