All of lore.kernel.org
 help / color / mirror / Atom feed
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.


             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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.