[Bug dynamic-link/19329] dl-tls.c assert failure at concurrent pthread_create and dlopen

["xujing99 at huawei dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=19329

xujing <xujing99 at huawei dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xujing99 at huawei dot com

--- Comment #35 from xujing <xujing99 at huawei dot com> ---
(In reply to cvs-commit@gcc.gnu.org from comment #31)
> The master branch has been updated by Szabolcs Nagy <nsz@sourceware.org>:
> 
> https://sourceware.org/git/gitweb.cgi?p=glibc.git;
> h=1387ad6225c2222f027790e3f460e31aa5dd2c54
> 
> commit 1387ad6225c2222f027790e3f460e31aa5dd2c54
> Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
> Date:   Wed Dec 30 19:19:37 2020 +0000
> 
>     elf: Fix data races in pthread_create and TLS access [BZ #19329]
>     
>     DTV setup at thread creation (_dl_allocate_tls_init) is changed
>     to take the dlopen lock, GL(dl_load_lock).  Avoiding data races
>     here without locks would require design changes: the map that is
>     accessed for static TLS initialization here may be concurrently
>     freed by dlclose.  That use after free may be solved by only
>     locking around static TLS setup or by ensuring dlclose does not
>     free modules with static TLS, however currently every link map
>     with TLS has to be accessed at least to see if it needs static
>     TLS.  And even if that's solved, still a lot of atomics would be
>     needed to synchronize DTV related globals without a lock. So fix
>     both bug 19329 and bug 27111 with a lock that prevents DTV setup
>     running concurrently with dlopen or dlclose.
>     
>     _dl_update_slotinfo at TLS access still does not use any locks
>     so CONCURRENCY NOTES are added to explain the synchronization.
>     The early exit from the slotinfo walk when max_modid is reached
>     is not strictly necessary, but does not hurt either.
>     
>     An incorrect acquire load was removed from _dl_resize_dtv: it
>     did not synchronize with any release store or fence and
>     synchronization is now handled separately at thread creation
>     and TLS access time.
>     
>     There are still a number of racy read accesses to globals that
>     will be changed to relaxed MO atomics in a followup patch. This
>     should not introduce regressions compared to existing behaviour
>     and avoid cluttering the main part of the fix.
>     
>     Not all TLS access related data races got fixed here: there are
>     additional races at lazy tlsdesc relocations see bug 27137.
>     
>     Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

this patch use dl_load_lock in _dl_allocate_tls_init, is there a problem when
dlopen a dynamic library which will call pthread_create? I think it will cause
dl_load_lock and dl_load_lock dead lock.

-- 
You are receiving this mail because:
You are on the CC list for the bug.