Date: Thu, 4 Mar 2004 18:58:33 +0000 From: Chris Smith <chris@nfluid.co.uk> To: Bruce M Simpson <bms@spc.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel SysV IPC defaults. Message-ID: <200403041858.33139.chris@nfluid.co.uk> In-Reply-To: <20040304134726.GL1875@saboteur.dek.spc.org> References: <200403031742.43986.chris@nfluid.co.uk> <20040304134726.GL1875@saboteur.dek.spc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403041858.33139.chris>