From: Thomas Gleixner <tglx@linutronix.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Akira Takeuchi <takeuchi.akr@jp.panasonic.com>,
linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
Carsten Emde <C.Emde@osadl.org>,
Manfred Spraul <manfred@colorfullife.com>
Subject: Re: [REGRESSION][PATCH] mqueue: Ignore the validity of abs_timeout parameter when message can be performed immediately
Date: Wed, 14 Mar 2012 23:08:53 +0100 (CET) [thread overview]
Message-ID: <alpine.LFD.2.02.1203142250500.2466@ionos> (raw)
In-Reply-To: <20120314144601.ccc50a68.akpm@linux-foundation.org>
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?
> > On 2.6.35+ kernel, mq_timed{send,receive} returns EINVAL incorrectly,
> > in this situation.
> >
> > I found this problem during the OPTS testcase
> > "conformance/interfaces/mq_timedreceive/10-2":
> >
> > # ./10-2.test
> > FAIL: the validity of abs_timeout is checked
> > Test FAILED
>
> Are you able to identify the commit which caused this regression? I'm
> guessing
>
> commit 9ca7d8e6834c40a99622bbe4a88aaf64313ae43c
> Author: Carsten Emde <C.Emde@osadl.org>
> AuthorDate: Fri Apr 2 22:40:20 2010 +0200
> Commit: Thomas Gleixner <tglx@linutronix.de>
> CommitDate: Tue Apr 6 21:50:03 2010 +0200
>
> mqueue: Convert message queue timeout to use hrtimers
Right, because nobody imagined that the specification would be as
asinine.
I'll pick it up and add a stable tag.
Sigh,
tglx
next prev parent reply other threads:[~2012-03-14 22:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-02 7:42 [REGRESSION][PATCH] mqueue: Ignore the validity of abs_timeout parameter when message can be performed immediately Akira Takeuchi
2012-03-14 21:46 ` Andrew Morton
2012-03-14 22:08 ` Thomas Gleixner [this message]
2012-03-15 0:28 ` Thomas Gleixner
2012-03-15 3:48 ` Linus Torvalds
2012-03-15 11:02 ` Thomas Gleixner
2012-03-16 5:11 ` Akira Takeuchi
2012-03-23 0:03 ` Akira Takeuchi
2012-03-23 9:01 ` Thomas Gleixner
2012-03-14 23:02 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.02.1203142250500.2466@ionos \
--to=tglx@linutronix.de \
--cc=C.Emde@osadl.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
--cc=takeuchi.akr@jp.panasonic.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox