[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2054433814.959851277495348646.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
Date: Fri, 25 Jun 2010 15:49:08 -0400 (EDT)
From: Ulrich Drepper <drepper@...hat.com>
To: Darren Hart <dvhltc@...ibm.com>
Cc: Ingo Molnar <mingo@...e.hu>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Thomas Gleixner <tglx@...utronix.de>,
Andreas Schwab <schwab@...hat.com>,
Danny Feng <dfeng@...hat.com>,
Jakub Jelinek <jakub@...hat.com>, linux-kernel@...r.kernel.org,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Oleg Nesterov <oleg@...hat.com>
Subject: Re: Q: sys_futex() && timespec_valid()
----- "Darren Hart" <dvhltc@...ibm.com> wrote:
> Unless there is some good reason to object to breaking the API that I
> am missing, I don't mind changing it to -ETIMEDOUT (although -EINVAL
> seems more intuitive to me).
It's only not intuitive because Oleg misrepresented or at least didn't describe the issue.
The kernel already catches invalid timespec values. Unfortunately the code used comes from the time when all timeouts where specified with relative values. In such situations negative tv_sec values were in fact invalid and rejected with EINVAL.
But for absolute timeouts tv_sec = -1 means a time before Epoch. This is not an invalid value, it just is one of many points in time which have passed and therefore the kernel has to respond with ETIMEDOUT.
This is no semantic change or anything like that. It pure and simply a bug fix. When Thomas worked on that come we simply missed updating the test for invalid timespec values.
The kernel code should be fixed to always check tv_nsec for < 0 and > 1000000000. But the tv_sec test for < 0 should be skipped if the timeout value is interpreted as an absolute time value.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists