public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "xujing99 at huawei dot com" <sourceware-bugzilla@sourceware.org>
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 05:06:18 +0000 [thread overview]
Message-ID: <bug-19329-131-grhsy9eefN@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-19329-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=19329
--- Comment #36 from xujing <xujing99 at huawei dot com> ---
(In reply to xujing from comment #35)
> (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.
dlopen will hold on dl_load_lock, and pthread_create will call
_dl_allocate_tls_init and then will hold on dl_load_lock. Finally, it will
cause dead lock.
--
You are receiving this mail because:
You are on the CC list for the bug.
next prev parent reply other threads:[~2021-09-11 5:06 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-19329-131@http.sourceware.org/bugzilla/>
2020-05-03 10:56 ` slyfox at inbox dot ru
2020-05-04 13:14 ` nsz at gcc dot gnu.org
2020-05-04 18:25 ` slyfox at inbox dot ru
2020-05-27 17:17 ` sourceware.org@the-compiler.org
2020-05-28 13:15 ` sourceware.org at devrx dot org
2020-07-08 20:15 ` sjkingo88 at gmail dot com
2020-09-09 22:12 ` jg at jguk dot org
2020-09-28 15:27 ` jg at jguk dot org
2020-10-09 10:51 ` jg at jguk dot org
2020-10-09 20:21 ` carlos at redhat dot com
2020-10-12 1:29 ` i.palachev at samsung dot com
2020-10-23 11:47 ` sebastien at debian dot org
2020-10-29 3:12 ` lvying.system.thoughts at gmail dot com
2020-11-11 8:31 ` stli at linux dot ibm.com
2020-12-01 2:15 ` lvying.system.thoughts at gmail dot com
2020-12-24 16:59 ` nsz at gcc dot gnu.org
2021-01-30 15:44 ` azhelev+sourceware at mailbox dot org
2021-02-07 23:04 ` carlos at redhat dot com
2021-02-17 16:00 ` nsz at gcc dot gnu.org
2021-02-23 2:48 ` carlos at redhat dot com
2021-03-15 11:45 ` shanzhikun at gmail dot com
2021-04-20 12:43 ` lilydjwg at gmail dot com
2021-05-11 16:17 ` cvs-commit at gcc dot gnu.org
2021-05-11 16:17 ` cvs-commit at gcc dot gnu.org
2021-05-11 16:17 ` cvs-commit at gcc dot gnu.org
2021-05-11 16:24 ` nsz at gcc dot gnu.org
2021-09-11 4:54 ` xujing99 at huawei dot com
2021-09-11 5:06 ` xujing99 at huawei dot com [this message]
2021-09-11 10:44 ` xujing99 at huawei dot com
2021-09-12 1:23 ` nsz at gcc dot gnu.org
2021-09-13 2:50 ` xujing99 at huawei dot com
2021-09-13 8:25 ` nsz at gcc dot gnu.org
2021-09-16 14:42 ` nsz at gcc dot gnu.org
2021-09-21 13:20 ` nsz at gcc dot gnu.org
2021-10-04 14:12 ` cvs-commit at gcc dot gnu.org
2021-10-19 12:23 ` cvs-commit at gcc dot gnu.org
2023-02-09 12:56 ` louisbenaze at gmail dot com
2023-02-09 13:11 ` jg at jguk dot org
2024-05-16 7:27 ` fweimer at redhat dot com
2024-05-16 7:31 ` fweimer at redhat dot com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-19329-131-grhsy9eefN@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=glibc-bugs@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).