Cleanup: Re-organise source dir Re-organise the sources, add a top level "src" and "include" dir and move relevant files. Disable autotools automated includes and define them manually. This fixes problems with collision of header names with system headers. Include the autoconf config.h in the default includes and remove it where it's explicitely included. Remove _GNU_SOURCE defines since it's detected at configure for platforms that requires it and added to the config.h. Signed-off-by: Michael Jeanson <mjeanson@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix: compat_futex should work-around futex signal-restart kernel bug 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.19 since commit e967ef022 "MIPS: Fix restart of indirect syscalls", but nevertheless, we should try to handle this kernel bug more gracefully than a user-space hang due to unexpected spurious ENOSYS return value. 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. The 4.2 kernel on parisc, and likely newer kernels too, are also affected by a similar issue. 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
Fix: handle sys_futex() FUTEX_WAIT interrupted by signal We need to handle EINTR returned by sys_futex() FUTEX_WAIT, otherwise a signal interrupting this system call could make sys_futex return too early, and therefore cause a synchronization issue. Ensure that the futex compatibility layer returns meaningful errors and errno when using poll() or pthread cond variables. Reported-by: Gerd Gerats <geg@ngncc.de> CC: Paul E. McKenney <paulmck@linux.vnet.ibm.com> CC: Lai Jiangshan <laijs@cn.fujitsu.com> CC: Stephen Hemminger <shemminger@vyatta.com> CC: Alan Stern <stern@rowland.harvard.edu> CC: lttng-dev@lists.lttng.org CC: rp@svcs.cs.pdx.edu Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix: compat_futex_noasync race condition The Userspace RCU compatibility layer around sys_futex has a race condition which makes pretty much all "benchmark" tests hang pretty quickly on non-Linux systems (tested on Mac OS X). I narrowed it down to a bug in compat_futex_noasync: this compat layer uses a single pthread mutex and condition variable for all callers, independently of their uaddr. The FUTEX_WAKE performs a pthread cond broadcast to all waiters. FUTEX_WAIT must then compare *uaddr with val to see which thread has been awakened. Unfortunately, the check was not done again after each return from pthread_cond_wait(), thus causing the race. This race affects threads using the futex_noasync() compatibility layer concurrently, thus it affects only on non-Linux systems. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix: compat futex duplicated lock and completion compat_futex.c has one instance included in each urcu shared object, as well as within some of the test applications. However, it is expected that an entire program interact with the same lock and completion variables. Therefore, define them as globally visible, but weak, so the entire program agree on which object should be used. Reported-by: Vladimir Nikulichev <nvs@tbricks.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
urcu: fix compat_futex_noasync() This patch fix two critical problems in the compatibility fallback of compact_futex_noasync(): 1) compat_futex_cond is not bound to any @uaddr, it services all @uaddr, if you wakeup only one thread(pthread_cond_signal), the @uaddr of this waking thread and the @uaddr of the woken-up thread may be different. The woken-up thread will very probably go to sleep again because his own condition is not true. *And* this waking thread(FUTEX_WAKE) wake up NOTHING. 2) If the caller want to wake up all waiting threads, he will use INT_MAX for @val, and: for (i = 0; i < INT_MAX; i++) pthread_cond_signal(&compat_futex_cond); becomes almost infinity loop. Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Futex: turn "int" into "int32_t" for portability Even though int is 32-bit on all architectures supported by liburcu so far, make it future-proof by uint a int32_t, which enforces the same type width used by the system call in the kernel. Using int32_t and not uint32_t to make comparison with 0 more straightforward. Reported-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Rename all memory primitives with prefix cmm_ In order to not pollute the userspace namespace for application using liburcu or any lib/apps linked with urcu, this patch if the first of three major refactor for naming convention. The cmm_ prefix is a short name for Concurrent Memory Model and was suggested by Mathieu Desnoyers and Paul E. Mckenney. Every memory primitives such as mb, wmb, rmb, and so on are renamed. Signed-off-by: David Goulet <david.goulet@polymtl.ca> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>