From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 4 10:56:06 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 562BE16A4CE for ; Thu, 4 Mar 2004 10:56:06 -0800 (PST) Received: from nfluid.plus.com (ors.orctel.co.uk [194.75.36.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DEE243D2D for ; Thu, 4 Mar 2004 10:56:05 -0800 (PST) (envelope-from chris@nfluid.plus.com) Received: from localhost (localhost [[UNIX: localhost]]) by nfluid.plus.com (8.11.6/8.11.2) id i24IwXM02494; Thu, 4 Mar 2004 18:58:33 GMT Content-Type: text/plain; charset="iso-8859-1" From: Chris Smith Organization: netFluid Technology Ltd To: Bruce M Simpson Date: Thu, 4 Mar 2004 18:58:33 +0000 User-Agent: KMail/1.4.3 References: <200403031742.43986.chris@nfluid.co.uk> <20040304134726.GL1875@saboteur.dek.spc.org> In-Reply-To: <20040304134726.GL1875@saboteur.dek.spc.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200403041858.33139.chris@nfluid.co.uk> cc: freebsd-hackers@freebsd.org Subject: Re: Kernel SysV IPC defaults. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2004 18:56:06 -0000 On Thursday 04 Mar 2004 13:47, Bruce M Simpson wrote: > On Wed, Mar 03, 2004 at 05:42:43PM +0000, Chris Smith wrote: > > Consider MSGMAX (max bytes in a message) and MSGMNB (max bytes in a > > queue) The defaults are MSGMAX > MSGMNB, which is clearly backwards. > > I see this. How about the attached patch? Thanks for the reply, I did some research in the interim and perhaps you = could=20 verify my findings/assumptions below if you've got a spare moment? This = goes=20 into some detail. Sorry :o( I don't think you can have more than (MSGSSZ*MSGSEG) bytes queued in tota= l by=20 the kernel. I've just been trawling through sysv_msg.c and either I've lost myself, o= r it=20 _might_ be broken. You see, traditionally the total space available for all messages (the po= ol)=20 is given by (MSGSSZ * MSSEG). Looking at the code the pool is allocated = with=20 this value... however the msgmax parameter is explicitly being set to thi= s=20 figure as well: msginfo.msgmax =3D msginfo.msgseg * msginfo.msgssz; msgpool =3D malloc(msginfo.msgmax, M_MSG, M_WAITOK); Normally you would expect to see MSGMNB < (MSGSSZ * MSSEG), but given th= e=20 code above, this equates to msgmnb < msgmax.... which if you're still wit= h me=20 says "max bytes in queue should be less than max bytes in a single messag= e". And how can that be? The way I 'm reading it is that queued messages consume message segments = from=20 msgpool. Once this pool is exhausted, then no more messages may be queue= d=20 _system wide_. I could be misreading the code here - put me right if I a= m:o) On closer examination, msgmax is never considered in the code, only that = there=20 are sufficient segments available with which to store a message (in the q= ueue=20 by indirectly checking MSGMNB). There are no checks that a single messag= e=20 does not exceed MSGMAX, and that is supposed to be trapped! This all implies that a single message can consume all msg segments alloc= ated=20 to a single queue (the code seems to confirm this also). The defaults may thus be incorrect as they mirror the code.... besides, i= t=20 looks like whatever you try to default MSGMAX to be it _always_ gets set = to=20 (MSGSSZ*MSGSEG) by the code above. I would suggest that msginfo.maxmsg should not be overwritten by (msgsssz= *=20 msseg), and that msgpool be malloced from the sum of (msgsssz * msseg)=20 directly. When queueing a message, a check should be that the msgsize do= es=20 not exceed msgmax. I think this will make the sysv_msg behave as documen= ted. Would you like me to generate a test suite for this problem and then perh= aps a=20 patch for sysv_msg.c should my findings above turn out to be correct? Incidentally, the same problem appears (with no surprise) with openBSD an= d=20 netBSD. I'm familiar with Solaris settings, and I've just checked a couple of oth= er=20 OS's and they concur with Solaris in that: MSGMAX =3D 2^n, for 6 < n < 16 and MSGMAX < MSGMNB and MSGMNB < (MSGSSZ*MSGSEG) Total pool size =3D (MSGSSZ*MSGSEG) > I can understand people still using the SYSV IPC mechanisms for the sak= e of > compatibility, but I suspect the purists are loathe to touch it. SYSV IPC (message queues) are incredibly useful if you want to pull messa= ges=20 out of the queue with a variable priority, regardless of queue FIFO order= =2E =20 I'm working hard on an alternative so I can drop sysV requirement, but it= 's=20 fraught with problems :o( Regards Chris > > BMS