All of lore.kernel.org
 help / color / mirror / Atom feed
From: Torsten Hilbrich <torsten.hilbrich@secunet.com>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	Darren Hart <dvhart@linux.intel.com>,
	tsmith201104@yahoo.com
Subject: [futex] Regression in 2.6.38 regarding FLAGS_HAS_TIMEOUT
Date: Wed, 13 Apr 2011 09:04:42 +0200	[thread overview]
Message-ID: <4DA54B0A.4090206@secunet.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

Hello,

I noticed that the behaviour of FUTEX_WAIT changed between 2.6.37 and
2.6.38. The error was initially found in a java program where a
Thread.sleep never returned after resuming from a suspend to ram.
Thread.sleep is implemented using pthread_cond_timedwait which itself
uses futex with the op FUTEX_WAIT.

The error can also be triggered with a simple test program (attached as
test-futex.c) which calls FUTEX_WAIT with a timeout of 200ms in a loop.
While running the test program the machine is suspended using "echo mem
> /sys/power/state".

After resume the futex syscall never returns. The return can be provoked
by sending the process a combination of SIGSTOP and SIGCONT.

The bug didn't occur in 2.6.37.

I found this bug report

https://bugzilla.kernel.org/show_bug.cgi?id=32922

which describes a related problem and presented a patch. This patch
(adding the FLAGS_HAS_TIMEOUT in futex_wait to the restart_block) fixes
the problem for my initial java problem and the test program.

I found the following pull request which probably introduced the
problem: https://lkml.org/lkml/2011/1/6/62

Thanks,

	Torsten



[-- Attachment #2: test-futex.c --]
[-- Type: text/x-csrc, Size: 759 bytes --]

#include <errno.h>
#include <linux/futex.h>
#include <stdio.h>
#include <string.h>
#include <sys/syscall.h>
#include <sys/time.h>
#include <unistd.h>

static inline int futex(int *uaddr, int op, int val,
			const struct timespec *timeout,
			int *uaddr2, int val3)
{
	return syscall(SYS_futex, uaddr, op, val,
		       timeout, uaddr2, val3);
}

static void futex_sleep(int ms)
{
	static int round;
	struct timespec ts;
	int condition = 0;
	int rc;
	fprintf(stderr, "Before sleep %d\n", ++round);
	ts.tv_sec = 0;
	ts.tv_nsec = ms * 1000L * 1000L;
	rc = futex(&condition, FUTEX_WAIT, condition, &ts, NULL, 0);
	fprintf(stderr, "After sleep (error: %s)\n",
		(rc < 0 ? strerror(errno) : "none"));
}

int main()
{
	while(1) {
		futex_sleep(200);
	}
	return 0;
}

                 reply	other threads:[~2011-04-13  7:04 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=4DA54B0A.4090206@secunet.com \
    --to=torsten.hilbrich@secunet.com \
    --cc=dvhart@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=tsmith201104@yahoo.com \
    /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.