Re: [REGRESSION][PATCH] mqueue: Ignore the validity of abs_timeout parameter when message can be performed immediately

[Thomas Gleixner <tglx@linutronix.de>]

On Wed, 14 Mar 2012, Thomas Gleixner wrote:
> On Wed, 14 Mar 2012, Andrew Morton wrote:
> 
> > On Fri, 02 Mar 2012 16:42:35 +0900
> > Akira Takeuchi <takeuchi.akr@jp.panasonic.com> wrote:
> > 
> > > This patch fixes up the regression problem of mq_timed{send,receive} syscall.
> > > 
> > > When a message of mqueue can be performed immediately,
> > > the validity of abs_timeout parameter should not be checked.
> > > 
> > > According to the manpage of mq_timedreceive:
> > >     Under no circumstance shall the operation fail with a timeout
> > >     if a message can be removed from the message queue immediately.
> > >     The validity of the abstime parameter need not be checked
> > >     if a message can be removed from the message queue immediately.
> 
> Those POSIX spec folks definitely have a seriously distorted
> relationship to timers and timekeeping.
> 
> So the caller knows upfront when he needs to provide a valid timespec
> and when not. So the users of mq_.... are into crystal ball
> programming or what?

Thinking more about it. The manpage according to

  git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git

does not mention that insanity at all.

So what the patch is referring to is the POSIX spec:

   http://pubs.opengroup.org/onlinepubs/009604499/functions/mq_timedsend.html
   http://pubs.opengroup.org/onlinepubs/009604499/functions/mq_timedreceive.html

Aside of my previous ranting about the insanity of that, the following
is actually open for interpretation:

 "The validity of the abstime parameter need not be checked if a
  message can be removed from the message queue immediately."

It's not necessary to check the validity of the abstime parameter, but
the spec does not forbid it either.

So for the sake of sanity we rather fix that test case and keep the
code as is. There haven't been regression reports from real world
applications within 2 years, so there is no point to add more
convolution to the mqueue code just to satisfy a random interpretation
of the spec by a test suite.

Again, there is no point to interpret it as "avoid the check" simply
because user space cannot know whether there is room to queue or
whether there is a message waiting. So requiring a valid timespec is
always the Right Thing to do.

Thanks,

	tglx