[patch] Re: dlopen() and dlclose() are not MT-safe? YES, esp. for libthr

Alexander Kabaev kabaev at gmail.com
Sat Mar 25 15:07:35 UTC 2006


On Fri, 24 Mar 2006 10:48:34 +0200
Kostik Belousov <kostikbel at gmail.com> wrote:

> I did understand the purpose of the thread mask code in
> libexec/rtld/rtld_lock.c, or, more precisely, the condition where
> this code works (for the context, see the mails with same subject on
> freebsd-hackers).
> 
> Look, that code assumes that blocking async signals would stop thread
> scheduler from doing preemption of the current thread. This works
> for libc_r, but fails in libpthread and libthr cases. libpthread
> provides implementation of the locks for rtld. But libthr does not !
> 
> As result, rtld exhibit races when used with libthr. In other words,
> libthr needs code to do proper locking.
> 
> Do you agree ? Does somebody already planned to do this work ?
> 
> Best regards,
> Kostik Belousov

 The thread mask only makes sense when flags are per-thread. I meant
to use it to detect PLT recursions from locking primitives exported to
rtld by the threads library as those are not allowed and threads
implementations are required to take special care to provide only
self-contained locks. 

 The 'default' lock implementation will not work with any library
other than libc_r, and even that holds true only for some definition of
"work". The dynamic loader never had a reliable locking and
furthermore, there was no way to make it work better without threading
library cooperation. This is why we came up with a set of callbacks
rtld expects every threading library to provide. libpthread was the
first where these callbacks were implemented. It comes as a surprise
that libthr did not have them, because David Xu was the one who did
most of the work on rtld locking callbacks in libpthread.

The def_thread_set_flag function use is racy and should be fixed.

-- 
Alexander Kabaev


More information about the freebsd-hackers mailing list