From: Oleg Nesterov <oleg@redhat.com>
To: Darren Hart <dvhltc@us.ibm.com>, Ingo Molnar <mingo@elte.hu>,
Linus Torvalds <torvalds@linux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Thomas Gleixner <tglx@linutronix.de>
Cc: Andreas Schwab <schwab@redhat.com>, Danny Feng <dfeng@redhat.com>,
Jakub Jelinek <jakub@redhat.com>,
Ulrich Drepper <drepper@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Q: sys_futex() && timespec_valid()
Date: Fri, 25 Jun 2010 21:20:08 +0200 [thread overview]
Message-ID: <20100625192008.GA25337@redhat.com> (raw)
Hello.
Another stupid question about the trivial problem I am going to ask,
just to report the authoritative answer back to bugzilla. The problem
is, personally I am not sure we should/can add the user-visible change
required by glibc maintainers, and I am in no position to suggest them
to fix the user-space code instead.
In short, glibc developers believe that sys_futex(ts) is buggy and
needs the fix to return -ETIMEDOUT instead of -EINVAL in case when
ts->tv_sec < 0 and the timeout is absolute.
Ignoring the possible cleanups/microoptimizations, something like this:
--- x/kernel/futex.c
+++ x/kernel/futex.c
@@ -2625,6 +2625,16 @@ SYSCALL_DEFINE6(futex, u32 __user *, uad
cmd == FUTEX_WAIT_REQUEUE_PI)) {
if (copy_from_user(&ts, utime, sizeof(ts)) != 0)
return -EFAULT;
+
+ // absolute timeout
+ if (cmd != FUTEX_WAIT) {
+ if (ts->tv_nsec >= NSEC_PER_SEC)
+ return -EINVAL;
+ if (ts->tv_sec < 0)
+ return -ETIMEDOUT;
+ }
+
+
if (!timespec_valid(&ts))
return -EINVAL;
------------------------------------------------------------------------
Otherwise, pthread_rwlock_timedwrlock(ts) hangs spinning in user-space
forever if ts->tv_sec < 0.
To clarify: this depends on libc version and arch.
This happens because pthread_rwlock_timedwrlock(rwlock, ts) on x86_64
roughly does:
for (;;) {
if (fast_path_succeeds(rwlock))
return 0;
if (ts->tv_nsec >= NSEC_PER_SEC)
return EINVAL;
errcode = sys_futex(FUTEX_WAIT_BITSET_PRIVATE, ts);
if (errcode == ETIMEDOUT)
return ETIMEDOUT;
}
and since the kernel return EINVAL due to !timespec_valid(ts), the
code above loops forever.
(btw, we have same problem with EFAULT, and this is considered as
a caller's problem).
IOW, pthread_rwlock_timedwrlock() assumes that in this case
sys_futex() can return nothing interesting except 0 or ETIMEDOUT.
I guess pthread_rwlock_timedwrlock() is not alone, but I didn't check.
So, the question: do you think we can change sys_futex() to make
glibc happy?
Or, do you think it is user-space who should check tv_sec < 0 if
it wants ETIMEDOUT with the negative timeout ?
Thanks,
Oleg.
next reply other threads:[~2010-06-25 19:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-25 19:20 Oleg Nesterov [this message]
2010-06-25 19:42 ` Q: sys_futex() && timespec_valid() Darren Hart
2010-06-25 19:49 ` Ulrich Drepper
2010-06-25 20:11 ` Thomas Gleixner
2010-06-28 13:58 ` Oleg Nesterov
2010-06-28 14:37 ` Jakub Jelinek
2010-06-28 15:02 ` Oleg Nesterov
2010-06-25 19:56 ` Mathieu Desnoyers
2010-06-25 19:59 ` Thomas Gleixner
2010-06-25 20:04 ` Ulrich Drepper
2010-06-25 20:25 ` Thomas Gleixner
2010-06-28 15:15 ` Linus Torvalds
2010-06-28 15:29 ` Andreas Schwab
2010-06-28 15:33 ` Thomas Gleixner
2010-06-28 16:04 ` Linus Torvalds
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=20100625192008.GA25337@redhat.com \
--to=oleg@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=dfeng@redhat.com \
--cc=drepper@redhat.com \
--cc=dvhltc@us.ibm.com \
--cc=jakub@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=schwab@redhat.com \
--cc=tglx@linutronix.de \
--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