Version: 1
-Previous: 97ff753994ee80869bcfce5c7e9683f154eec8b9
-Head: c488a747b95a7b2f3092c2d26185d42ab0e69645
+Previous: 76c63745415a52c6b11702275582ad120c688673
+Head: d30bdb2dc3790f8b9ca2b1ee538af60020bc24da
Applied:
+ fork-fix: d30bdb2dc3790f8b9ca2b1ee538af60020bc24da
Unapplied:
dbg-fork: 5679a32af8305db3c0406f9abb961259304a384a
af_ib: 2e4bfa467343c57c68616c1922c01765df3ed1db
--- /dev/null
+Bottom: 30191aa638f3f574e67a71c82fa7771bcc620c52
+Top: 30191aa638f3f574e67a71c82fa7771bcc620c52
+Author: Sean Hefty <sean.hefty@intel.com>
+Date: 2012-08-23 11:20:08 -0700
+
+rspreload: Avoid rsocket calls until after fork
+
+When an rsocket call is made before an application calls fork(),
+the forked applications can hang. This can be seen by running
+netserver and two netperf clients simultaneously. The second
+netperf client will eventually stop performing data transfers.
+
+LD_PRELOAD=librspreload.so netserver -D
+
+LD_PRELOAD=librspreload.so netperf -v2 -c -C -H 192.168.0.101 -l30
+LD_PRELOAD=librspreload.so netperf -v2 -c -C -H 192.168.0.101 -l30
+
+It's not clear what the specific problem is. The best guess is
+that libibverbs or the provider library (e.g. libmlx4) perform
+some initialization, such as mmap'ing device memory, which does not
+work when fork is called.
+
+As a work-around, avoid calling rsocket routines until immediately
+before they are needed. This allows the process to fork before
+the libraries are initialized.
+
+Signed-off-by: Sean Hefty <sean.hefty@intel.com>
+
+
+---
+
+