"Markert, Alexander" <[email protected]> writes:
> Hi, Hi, > the length of the data to be sent and in addition the length of the > associated control message (e.g. the source address: IP_SENDSRCADDR) musn't > exceed the maximum size of the socket's send buffer (SO_SNDBUF). > Otherwise EMSGSIZE is returned. That is ok. > > However, if the data to be sent fits into the send buffer, but exceeds in > combination with the control message: > - either EWOULDBLOCK is returned when using non-blocking IO or > - send operation blocks in sbwait when using blocking IO > > It seems that this situation will never dissolve, i.e. the sending > application will be blocked forever. > > In our opinion either EMSGSIZE should be returned instead in this case > (like e.g. FreeBSD 11.0 does) or OpenBSD should reserve some space > (comparable to MSG_OOB) in addition to the maximum size of the socket's > send buffer for the control messages in order to avoid such problems. > > What do you think about that behavior and the described alternatives? Control messages are tricky. One port (net/dnsmasq) is currently failing, and appears to hang like you describe. The issue is related to control messages, but it's not a lack of send buffer space. So how can one reproduce the bug you're talking about? Do you have a test case? -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
