padsp: dlsym lookup on demand can lead to deadlocks
Submitted by Felipe Sateler
Assigned to pul..@..op.org
Description
Forwarded from a debian bug[1].
Summary from Mike Hommey:
- something calls access() before jemalloc is initialized.
- access() is caught by padsp, which locks a mutex, and resolves the original access symbol with dlsym().
- dlsym() ends up allocating memory, which triggers jemalloc initialization code.
- jemalloc init code open()s /proc/cpuinfo.
- open() is caught by padsp, which locks a mutex before resolving the original open symbol with dlsym().
Except that it is using the same mutex as the first time...
Really, the dlsym lookup on demand seems a bad idea, and here we hit a really bad corner case of that implementation. Even using separate mutexes wouldn't solve it all: imagine the original call wasn't access(), but open(), instead.
The best thing IMHO would be to have a constructor function that does the symbol resolution at startup.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550674