Discourage use of glibc pthread_atfork() for call_rcu handlers due to
its inappropriate assumptions about single-threadedness while pthread
atfork handlers are executing. This results in hangs within the glibc
memory allocator.
Signed-off-by: Mathieu Desnoyers <[email protected]>
---
diff --git a/README b/README
index 83330ea..2d29c1d 100644
--- a/README
+++ b/README
@@ -273,7 +273,20 @@ Interaction with fork()
must invoke call_rcu_before_fork() before the fork() and
call_rcu_after_fork_parent() after the fork(). The child
process must invoke call_rcu_after_fork_child().
- These three APIs are suitable for passing to pthread_atfork().
+ Even though these three APIs are suitable for passing to
+ pthread_atfork(), use of pthread_atfork() is *STRONGLY
+ DISCOURAGED* for programs calling the glibc memory allocator
+ (malloc(), calloc(), free(), ...) within call_rcu callbacks.
+ This is due to limitations in the way glibc memory allocator
+ handles calls to the memory allocator from concurrent threads
+ while the pthread_atfork() handlers are executing.
+ Combining e.g.:
+ * call to free() from callbacks executed within call_rcu worker
+ threads,
+ * executing call_rcu atfork handlers within the glibc pthread
+ atfork mechanism,
+ will sometimes trigger interesting process hangs. This usually
+ hangs on a memory allocator lock within glibc.
Thread Local Storage (TLS)
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
