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
| ||
|
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/
Powered by blists - more mailing lists