Messages in this thread | | | Date | Thu, 15 Mar 2012 01:28:38 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [REGRESSION][PATCH] mqueue: Ignore the validity of abs_timeout parameter when message can be performed immediately |
| |
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
| |