From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CB025385840C; Sat, 11 Sep 2021 04:54:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CB025385840C From: "xujing99 at huawei dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/19329] dl-tls.c assert failure at concurrent pthread_create and dlopen Date: Sat, 11 Sep 2021 04:54:02 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.22 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: xujing99 at huawei dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: nszabolcs at gmail dot com X-Bugzilla-Target-Milestone: 2.34 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2021 04:54:03 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D19329 xujing changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xujing99 at huawei dot com --- Comment #35 from xujing --- (In reply to cvs-commit@gcc.gnu.org from comment #31) > The master branch has been updated by Szabolcs Nagy : >=20 > https://sourceware.org/git/gitweb.cgi?p=3Dglibc.git; > h=3D1387ad6225c2222f027790e3f460e31aa5dd2c54 >=20 > commit 1387ad6225c2222f027790e3f460e31aa5dd2c54 > Author: Szabolcs Nagy > Date: Wed Dec 30 19:19:37 2020 +0000 >=20 > elf: Fix data races in pthread_create and TLS access [BZ #19329] >=20=20=20=20=20 > 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. >=20=20=20=20=20 > _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. >=20=20=20=20=20 > 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. >=20=20=20=20=20 > 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. >=20=20=20=20=20 > Not all TLS access related data races got fixed here: there are > additional races at lazy tlsdesc relocations see bug 27137. >=20=20=20=20=20 > Reviewed-by: Adhemerval Zanella this patch use dl_load_lock in _dl_allocate_tls_init, is there a problem wh= en dlopen a dynamic library which will call pthread_create? I think it will ca= use dl_load_lock and dl_load_lock dead lock. --=20 You are receiving this mail because: You are on the CC list for the bug.=