The unreliability of AF_UNIX datagram sockets

[Ken Brown]

On 5/4/2021 7:06 AM, Corinna Vinschen wrote:
> On May  3 16:50, Ken Brown wrote:
>> On 5/3/2021 3:48 PM, Ken Brown wrote:
>>> On 5/3/2021 2:40 PM, Corinna Vinschen wrote:
>>>> On May  3 12:56, Ken Brown wrote:
>>>>> On 5/3/2021 11:45 AM, Corinna Vinschen wrote:
>>>>>> 7. The idea of _mq_recv partial reads is entirely broken.  Given that
>>>>>>       the information in the queue consists of header info plus payload,
>>>>>>       the entire block has to be read, and then a new block with fixed
>>>>>>       header and shortened payload has to be rewritten with bumped priority.
>>>>>>       This in turn can only be performed by the AF_UNIX code, unless we
>>>>>>       expect knowledge of the AF_UNIX packet layout in the mqueue code.
>>>>>
>>>>> The partial read is actually OK as is, since it's comparable to what happens
>>>>> on a partial read from a pipe.  I already have AF_UNIX code (on the
>>>>> topic/af_unix branch) that deals with that.  A boolean variable _unread
>>>>> keeps track of whether there's unread data from a previous partial read.  If
>>>>> so, the next read just reads data without expecting a header.
>>>>
>>>> Ok, never mind.
>>>>
>>>> One advantage of the mqueue when utilized as above would be that this
>>>> kind of state info is not required.  The content of a packet would
>>>> always be self-contained and bumping the priority would automagically
>>>> move the packet content to the top of the queue.  But that's just
>>>> idle musing at this point.
>>>
>>> I thought about that but rejected it for the following reason: Suppose
>>> the receiver reads a message and tries to rewrite it with modified
>>> header, shortened payload, and bumped priority.  The sender might have
>>> already written more messages between the read and the write, and the
>>> queue could be full.
>>>
>>> Now that I'm rethinking this, however, maybe we could get around that
>>> problem with an internal _mq_lock function that would block senders
>>> while the receiver decides whether it needs to do a partial read.
>>
>> Alternatively, _mq_recv could accept an _MQ_LOCK flag, which means "don't
>> release the mutex", and then there could be an _mq_unlock function, which
>> simply releases the mutex.
> 
> That's an idea.  However, I think this is something we can push back for
> now, and ultimately we can use any of the above solutions which makes most
> sense.  Implemanting a defered unlock if required is not much of a problem.

I've begun working on an mqueue-based implementation of AF_UNIX sockets, on a 
new topic/af_unix_mq branch.  I've implemented accept and connect and lightly 
tested them, and I've implemented sendmsg (not yet tested).  I'll start on 
recvmsg next, and then I'll be able to test sending/receiving.

While working on sendmsg, I thought of another useful thing that the mqueue code 
could provide: an internal _mq_send function that returns EPIPE if no one has 
the mqueue open for reading.  This plays the role of the STATUS_PIPE_IS_CLOSED 
macro in the pipe implementation.

Ken