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: <1400168793.6946.10.camel@buesod1.americas.hpqcorp.net>
Date:	Thu, 15 May 2014 08:46:33 -0700
From:	Davidlohr Bueso <davidlohr@...com>
To:	Manfred Spraul <manfred@...orfullife.com>
Cc:	akpm@...ux-foundation.org, aswin@...com,
	linux-kernel@...r.kernel.org,
	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Subject: Re: [PATCH 5/5] ipc,msg: loosen check for full queue

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 ()
-- 
1.8.1.4




--
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/