From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Jon Bernard <jbernard@debian.org>
Cc: Michael Jeanson <mjeanson@efficios.com>,
Ralf Baechle <ralf@linux-mips.org>,
linux-mips <linux-mips@linux-mips.org>,
linux-kernel@vger.kernel.org,
"James E.J. Bottomley" <jejb@parisc-linux.org>,
Helge Deller <deller@gmx.de>,
linux-parisc <linux-parisc@vger.kernel.org>,
Ed Swierk <eswierk@skyportsystems.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [RFC PATCH urcu on mips, parisc] Fix: compat_futex should work-around futex signal-restart kernel bug
Date: Thu, 17 Dec 2015 12:54:12 +0000 (UTC) [thread overview]
Message-ID: <663068619.259007.1450356852694.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <1450303792-27470-1-git-send-email-mathieu.desnoyers@efficios.com>
[-- Attachment #1: Type: text/plain, Size: 3768 bytes --]
----- On Dec 16, 2015, at 5:09 PM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:
> When testing liburcu on a 3.18 Linux kernel, 2-core MIPS (cpu model :
> Ingenic JZRISC V4.15 FPU V0.0), we notice that a blocked sys_futex
> FUTEX_WAIT returns -1, errno=ENOSYS when interrupted by a SA_RESTART
> signal handler. This spurious ENOSYS behavior causes hangs in liburcu
> 0.9.x. Running a MIPS 3.18 kernel under a QEMU emulator exhibits the
> same behavior. This might affect earlier kernels.
>
> This issue appears to be fixed in 3.18.y stable kernels and 3.19, but
> nevertheless, we should try to handle this kernel bug more gracefully
> than a user-space hang due to unexpected spurious ENOSYS return value.
It's actually fixed in 3.19, but not in 3.18.y stable kernels. The
Linux kernel upstream fix commit is:
e967ef02 "MIPS: Fix restart of indirect syscalls"
I've created a small test program that could also be used on parisc
to check if it suffers from the same issue (see attached).
On bogus mips kernels, we see the following output:
[OK] Test program with pid: 5748 SIGUSR1 handler
[FAIL] futex returns -1, Function not implemented
Let me know if someone can try it out on a parisc kernel.
Thanks!
Mathieu
>
> Therefore, fallback on the "async-safe" version of compat_futex in those
> situations where FUTEX_WAIT returns ENOSYS. This async-safe fallback has
> the nice property of being OK to use concurrently with other FUTEX_WAKE
> and FUTEX_WAIT futex() calls, because it's simply a busy-wait scheme.
>
> We suspect that parisc might be affected by a similar issue (Debian
> build bots reported a similar hang on both mips and parisc), but we do
> not have access to the hardware required to test this hypothesis.
>
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> CC: Michael Jeanson <mjeanson@efficios.com>
> CC: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> CC: Ralf Baechle <ralf@linux-mips.org>
> CC: linux-mips@linux-mips.org
> CC: linux-kernel@vger.kernel.org
> CC: "James E.J. Bottomley" <jejb@parisc-linux.org>
> CC: Helge Deller <deller@gmx.de>
> CC: linux-parisc@vger.kernel.org
> ---
> compat_futex.c | 2 ++
> urcu/futex.h | 12 +++++++++++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/compat_futex.c b/compat_futex.c
> index b7f78f0..9e918fe 100644
> --- a/compat_futex.c
> +++ b/compat_futex.c
> @@ -111,6 +111,8 @@ end:
> * _ASYNC SIGNAL-SAFE_.
> * For now, timeout, uaddr2 and val3 are unused.
> * Waiter will busy-loop trying to read the condition.
> + * It is OK to use compat_futex_async() on a futex address on which
> + * futex() WAKE operations are also performed.
> */
>
> int compat_futex_async(int32_t *uaddr, int op, int32_t val,
> diff --git a/urcu/futex.h b/urcu/futex.h
> index 4d16cfa..a17eda8 100644
> --- a/urcu/futex.h
> +++ b/urcu/futex.h
> @@ -73,7 +73,17 @@ static inline int futex_noasync(int32_t *uaddr, int op,
> int32_t val,
>
> ret = futex(uaddr, op, val, timeout, uaddr2, val3);
> if (caa_unlikely(ret < 0 && errno == ENOSYS)) {
> - return compat_futex_noasync(uaddr, op, val, timeout,
> + /*
> + * The fallback on ENOSYS is the async-safe version of
> + * the compat futex implementation, because the
> + * async-safe compat implementation allows being used
> + * concurrently with calls to futex(). Indeed, sys_futex
> + * FUTEX_WAIT, on some architectures (e.g. mips), within
> + * a given process, spuriously return ENOSYS due to
> + * signal restart bugs on some kernel versions (e.g.
> + * Linux kernel 3.18 and possibly earlier).
> + */
> + return compat_futex_async(uaddr, op, val, timeout,
> uaddr2, val3);
> }
> return ret;
> --
> 2.1.4
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: test-sigrestart-futex.c --]
[-- Type: text/x-c++src; name=test-sigrestart-futex.c, Size: 1440 bytes --]
#define _GNU_SOURCE
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <signal.h>
#include <stdlib.h>
#include <errno.h>
#include <sys/syscall.h>
static int value = -1;
#define FUTEX_WAIT 0
#define FUTEX_WAKE 1
static int futex(int32_t *uaddr, int op, int32_t val,
const struct timespec *timeout, int32_t *uaddr2, int32_t val3)
{
return syscall(__NR_futex, uaddr, op, val, timeout,
uaddr2, val3);
}
static void sighandler(int signo, siginfo_t *siginfo, void *context)
{
fprintf(stderr, "[OK] Test program with pid: %d SIGUSR1 handler\n",
getpid());
}
int main(int argc, char **argv)
{
struct sigaction act;
pid_t pid, wait_pid;
int ret;
fprintf(stderr, "Testing futex sigrestart. Stop with CTRL-c.\n",
getpid());
act.sa_sigaction = sighandler;
act.sa_flags = SA_SIGINFO | SA_RESTART;
//act.sa_flags = SA_SIGINFO;
sigemptyset(&act.sa_mask);
ret = sigaction(SIGUSR1, &act, NULL);
if (ret)
abort();
pid = fork();
if (pid > 0) {
/* parent */
for (;;) {
ret = kill(pid, SIGUSR1);
if (ret) {
perror("kill");
abort();
}
sleep(1);
}
} else {
if (pid < 0) {
abort();
}
/* child */
for (;;) {
ret = futex(&value, FUTEX_WAIT, -1, NULL, NULL, 0);
if (ret < 0) {
fprintf(stderr, "[FAIL] futex returns %d, %s\n",
ret, strerror(errno));
} else {
fprintf(stderr, "[FAIL] futex returns %d (unexpected)\n",
ret);
}
}
}
return 0;
}
next prev parent reply other threads:[~2015-12-17 12:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 22:09 [RFC PATCH urcu on mips, parisc] Fix: compat_futex should work-around futex signal-restart kernel bug Mathieu Desnoyers
2015-12-17 12:54 ` Mathieu Desnoyers [this message]
2015-12-17 13:16 ` Ed Swierk
2015-12-17 16:22 ` Aw: " Helge Deller
2015-12-18 19:58 ` Mathieu Desnoyers
2015-12-18 20:42 ` Helge Deller
2015-12-19 10:37 ` Helge Deller
2015-12-20 14:11 ` Mathieu Desnoyers
2015-12-20 15:37 ` Helge Deller
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=663068619.259007.1450356852694.JavaMail.zimbra@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=deller@gmx.de \
--cc=eswierk@skyportsystems.com \
--cc=gregkh@linuxfoundation.org \
--cc=jbernard@debian.org \
--cc=jejb@parisc-linux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-parisc@vger.kernel.org \
--cc=mjeanson@efficios.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=ralf@linux-mips.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