Don't use the electric fence in multithreaded code
authorBarret Rhoden <brho@cs.berkeley.edu>
Tue, 10 Jul 2018 19:51:38 +0000 (15:51 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Tue, 10 Jul 2018 19:51:38 +0000 (15:51 -0400)
The efence doesn't work with uthreads.  Efence intercepts malloc() et al.
When a uthread exits, its TLS is cleaned up.  Ultimately, this calls into
glibc, which calls free() on the TLS region in _dl_deallocate_tls(). That
region was allocated with __libc_memalign() in _dl_allocate_tls_storage().
efence can intercept the free(), but not the _libc function.

Pending other changes, we shouldn't use uthreads and the efence.  One
option would be to briefly disable the efence.  Another would be to not
actually free the TLS if the efence is linked in.  Neither are good
options.

For now, we'd like to not crash our utests.  The only code using it was
utests - some of which would break in a somewhat racy manner.

You can still link in the efence on demand.  If you do, I'd hack up your
2LS to have threads sleep forever when they finish (pthread.c, look for the
start_routine).

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
user/utest/Makefile

index eb50640..17089ea 100644 (file)
@@ -10,7 +10,7 @@ SRCDIR :=
 OBJDIR := $(SRCDIR)obj
 INCDIR = $(SRCDIR)include
 
-LDLIBS := -lpthread -lbenchutil -lm -liplib -lndblib -lelectric-fence
+LDLIBS := -lpthread -lbenchutil -lm -liplib -lndblib
 
 uc = $(shell echo $(1) | tr a-z A-Z)