Re: [PATCH 5/5] ipc,msg: loosen check for full queue

[Manfred Spraul <manfred@colorfullife.com>]

Hi Davidlohr, Hi Andrew,

On 05/13/2014 10:27 PM, Davidlohr Bueso wrote:
> When sending a message, we must guarantee that there will be
> enough room in the queue to add it, otherwise wait until space
> becomes available -- which requires blocking the calling task.
> Currently, this relies meeting both of the following conditions:
>
> (i) The new msg size + current size is lower than the queue's max size.
> (ii) The current amount of messages in the queue + 1 (this msg) is lower
>       than the queue's max size.
>
> While (i) is obvious and well documented in the msgsnd(2) manpage, the
> second one is far more ambiguous and does not serve the purpose, as we do
> not control the amount of messages in the queue (unlike posix queues do).
> Thus remove (ii) and loosen how we check for space.
I know that (ii) is undocumented and not part of SUS, but I think it is 
required:
Otherwise it would be possible to use up an infinite amount of locked 
memory by sending 0-byte messages.

I added it some long time ago, and at that time I didn't check what the 
other sysv msg implementation were doing.

 From a quick search:

FreeBSD:
- Optional: RACCT_MSGQQUEUED
- Always: The number of messages is limited due to a global array 
(limited to MSGTQL entries: array msghdrs, free list  free_msghdrs)

http://fxr.watson.org/fxr/source/kern/sysv_msg.c

Opensolaris:
- Also a limit of the number of messages:
http://fxr.watson.org/fxr/source/common/os/msg.c?v=OPENSOLARIS;im=bigexcerpts#L1166

- it appears that it is related to MSGTQL:
http://fxr.watson.org/fxr/source/common/os/msg.c?v=OPENSOLARIS;im=bigexcerpts#L652

I.e.: We cannot remove the check unless we add another mechanism that 
limits the number of messages.

--
     Manfred