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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <537608D8.7030000@gmail.com>
Date:	Fri, 16 May 2014 14:47:20 +0200
From:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:	Davidlohr Bueso <davidlohr@...com>,
	Manfred Spraul <manfred@...orfullife.com>
CC:	mtk.manpages@...il.com, akpm@...ux-foundation.org, aswin@...com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/5] ipc,msg: loosen check for full queue


Hi Davidlohr,

On 05/15/2014 05:46 PM, Davidlohr Bueso wrote:
> On Thu, 2014-05-15 at 06:20 +0200, Manfred Spraul wrote:
>> Hi Davidlohr,
>>
>> On 05/14/2014 09:50 PM, Davidlohr Bueso wrote:
>>> Do you have any preferences? I can cook up a patch if you think that
>>> this merits Linux having MSGTQL.
>> MSGTQL means a global counter - therefore zero scalability. That's why I 
>> didn't implement it when I noticed the issue with 0-byte messages.
> 
> Hmmm so I was actually thinking of calculating it on demand, but after a
> closer look, we don't track each queue in the system, which would have
> made this rather trivial.
> 
> We do however have plenty of similar counters in the kernel, and the
> natural way of dealing with the scalability issue is using percpu
> counters. But I won't argue much if we leave it as it is, it's been like
> that since almost forever and no one is complaining but me.
> 
> Andrew, could you please drop this patch from -mm, I'll send another one
> to add a comment instead.
> 
>>> Worst case scenario, we should update the msgsnd(2) manpage and document
>>> this unique Linux behavior.
>> I would document the current behavior.
> 
> Cc'ing Michael. Here is a vague attempt to update our manpage, feel free
> to update it to your taste.
> 
> Thanks,
> Davidlohr
> 
> 8<------------------------------------------------------------
> From: Davidlohr Bueso <davidlohr@...com>
> Subject: [PATCH] msgop.2: Document full queue criteria
> 
> Explicitly mention the two conditions we rely on when
> checking if a message queue is full when calling msgsnd(2).
> 
> Signed-off-by: Davidlohr Bueso <davidlohr@...com>
> ---
>  man2/msgop.2 | 22 +++++++++++++++++++---
>  1 file changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/man2/msgop.2 b/man2/msgop.2
> index 3f5bc36..b4c8c04 100644
> --- a/man2/msgop.2
> +++ b/man2/msgop.2
> @@ -105,13 +105,29 @@ by
>  If sufficient space is available in the queue,
>  .BR msgsnd ()
>  succeeds immediately.
> -(The queue capacity is defined by the
> -.I msg_qbytes
> +The queue capacity is governed by the
> +.I msg_qbytes 
>  field in the associated data structure for the message queue.
>  During queue creation this field is initialized to
>  .B MSGMNB
>  bytes, but this limit can be modified using
> -.BR msgctl (2).)
> +.BR msgctl (2).
> +A full queue is defined by two factors :
> +.IP * 2
> +The new msg size + current size of the queue is greater than the 
> +queue's maximum size (the
> +.I msg_qbytes
> +field).
> +.IP *
> +The current amount of messages in the queue + 1 (the new msg) is 
> +greater than the queue's maximum size (the
> +.I msg_qbytes
> +field). This is necessary to prevent users from using infinite 
> +amounts of locked memory (used by the kernel for headers) by 
> +sending 0-byte messages. This is equivalent to the traditional
> +MSGTQL parameter present in many Unix systems. This behavior
> +is unique to Linux.
> +.PP
>  If insufficient space is available in the queue, then the default
>  behavior of
>  .BR msgsnd ()


I applied, and reworded a little. Also: I dropped the piece about
MSGTQL, since it is not quite right. As noted elsewhere on the page
MSGTQL is a *system-wide* (not per-queue) limit on the number of
messages in all MQs. Also: I dropped the piece saying this is unique
to Linux. I believe that's true, but it implies there's a lot
more standardization around these limits than there actually is
in my observation.

Thanks for the patch!

Cheers,

Michael

Cheers,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/