Re: Expected msgrcv(2) behaviour with msgsz > SSIZE_MAX ?

[Nicolas Joly <njoly%pasteur.fr@localhost>]

On Fri, Jan 02, 2009 at 04:50:32PM +0000, Christos Zoulas wrote:
> In article <20090102153241.GA102025%medusa.sis.pasteur.fr@localhost>,
> Nicolas Joly  <njoly%pasteur.fr@localhost> wrote:
> >
> >While running LTP (Linux Testsuite Project) testcases under
> >compat_linux on my -current NetBSD/amd64 workstation, i discovered
> >that a testcase for msgrcv(2) syscall with msgsz < 0 was hanging
> >instead of failing with EINVAL.
> >
> >Looking into this one, i noticed that the syscall man page state that
> >a negative msgsz value make it fail with errno set to EINVAL, but the
> >corresponding code does not seems to match.
> >
> >As size_t type is unsigned, this can never happen ... But, at the same
> >time, the OpenGroup specification says that `msgsz > SSIZE_MAX' is
> >implementation dependant (test i can easily convert to `(ssize_t)msgsz
> >< 0', which was probably meant).
> >
> >I'm pretty sure that our implementation does handle this nicely. Can
> >someone confirm that both man page and compat linux emulation needs to
> >be fixed ?
> 
> The manual page needs to be fixed to remove the comment that < 0 == EINVAL,
> and say that:
> 
> In this implementation if the value of msgsz exceeds SSIZE_MAX,
> .Fn msgrcv 
> will wait forever for a message to arrive.
> 
> or we should just check and return -1/E2BIG or EINVAL, which seems more
> useful to me.

I was thinking about this a little more, and noticed that msgrcv will
return negatives values for msgsz exceeding SSIZE_MAX ... in that
range, a msgsz value of SIZE_MAX will make the syscall return a value
of -1 as bytes received which will be hard to distinguish from an
error.

Even if this more a theorically problem (conditions are hard to set up
...), i'm tempted now to restrict msgsz up to SSIZE_MAX (msgsnd should
be adjusted too for consistency).

Will try to prepare a patch in the next few days ...

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.