unix/stream: do not put empty mbufs on the socket

[glebius]

Summary

It is a legitimate case to use sendmsg(2) to send control only, with zero
bytes of data and then recvmsg(2) them with zero length iov, receiving
control only. This sendmsg(2)+recmsg(2) would leave a zero length mbuf on
the top of the socket buffer. If you now try to repeat this combo again,
your recvmsg(2) would not return control data, because it sits behind an
MT_DATA mbuf and you have provided zero length uio_resid. IMHO, best
strategy to deal with zero length buffers in a chain is to not put them
there in the first place. Thus, solve this right in uipc_send() instead
of touching soreceive_generic().

[markj]

sys/kern/uipc_usrreq.c

1005

Presumably you plan to remove the print before committing.

1013

So the right behaviour for SEQPACKET sockets is still to receive the 0-length message?

[glebius]

sys/kern/uipc_usrreq.c

1005

Oops, thanks :)

1013

At this point I don't care about them. This file marks them as PR_ATOMIC, which makes soreceive_generic() threat them like datagram sockets, which is against the specification. They are also marked as PR_ADDR, but they don't return sockaddr. This &sun_noname is a crutch to create a boundary record, the address is not returned in recv(2). There is XXXRW comment down there, but I'm not sure PR_ADDR and the crutch are required really, PR_ATOMIC should be enough.

Anyway, in my new uipc_soreceive_stream_or_seqpacket() they will be treated according to specification. Some tests might need an adjustments and new tests need to be written. Right now I'm getting close to all SOCK_STREAM test passed and then will work on SEQPACKET.

[glebius]

Remove debug printfs.

[markj]

sys/kern/uipc_usrreq.c

1003