public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/30785] Always call destructors in reverse constructor order Date: Mon, 11 Sep 2023 07:27:44 +0000 [thread overview] Message-ID: <bug-30785-131-09mRkc9S8g@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-30785-131@http.sourceware.org/bugzilla/> https://sourceware.org/bugzilla/show_bug.cgi?id=30785 Florian Weimer <fweimer at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Florian Weimer <fweimer at redhat dot com> --- Fixed in 2.39 via: commit 6985865bc3ad5b23147ee73466583dd7fdf65892 Author: Florian Weimer <fweimer@redhat.com> Date: Fri Sep 8 12:32:14 2023 +0200 elf: Always call destructors in reverse constructor order (bug 30785) The current implementation of dlclose (and process exit) re-sorts the link maps before calling ELF destructors. Destructor order is not the reverse of the constructor order as a result: The second sort takes relocation dependencies into account, and other differences can result from ambiguous inputs, such as cycles. (The force_first handling in _dl_sort_maps is not effective for dlclose.) After the changes in this commit, there is still a required difference due to dlopen/dlclose ordering by the application, but the previous discrepancies went beyond that. A new global (namespace-spanning) list of link maps, _dl_init_called_list, is updated right before ELF constructors are called from _dl_init. In dl_close_worker, the maps variable, an on-stack variable length array, is eliminated. (VLAs are problematic, and dlclose should not call malloc because it cannot readily deal with malloc failure.) Marking still-used objects uses the namespace list directly, with next and next_idx replacing the done_index variable. After marking, _dl_init_called_list is used to call the destructors of now-unused maps in reverse destructor order. These destructors can call dlopen. Previously, new objects do not have l_map_used set. This had to change: There is no copy of the link map list anymore, so processing would cover newly opened (and unmarked) mappings, unloading them. Now, _dl_init (indirectly) sets l_map_used, too. (dlclose is handled by the existing reentrancy guard.) After _dl_init_called_list traversal, two more loops follow. The processing order changes to the original link map order in the namespace. Previously, dependency order was used. The difference should not matter because relocation dependencies could already reorder link maps in the old code. The changes to _dl_fini remove the sorting step and replace it with a traversal of _dl_init_called_list. The l_direct_opencount decrement outside the loader lock is removed because it appears incorrect: the counter manipulation could race with other dynamic loader operations. tst-audit23 needs adjustments to the changes in LA_ACT_DELETE notifications. The new approach for checking la_activity should make it clearer that la_activty calls come in pairs around namespace updates. The dependency sorting test cases need updates because the destructor order is always the opposite order of constructor order, even with relocation dependencies or cycles present. There is a future cleanup opportunity to remove the now-constant force_first and for_fini arguments from the _dl_sort_maps function. Fixes commit 1df71d32fe5f5905ffd5d100e5e9ca8ad62 ("elf: Implement force_first handling in _dl_sort_maps_dfs (bug 28937)"). Reviewed-by: DJ Delorie <dj@redhat.com> Backports in progress. -- You are receiving this mail because: You are on the CC list for the bug.
next prev parent reply other threads:[~2023-09-11 7:27 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-08-22 10:48 [Bug dynamic-link/30785] New: " fweimer at redhat dot com 2023-08-22 10:49 ` [Bug dynamic-link/30785] " fweimer at redhat dot com 2023-08-22 10:49 ` fweimer at redhat dot com 2023-08-22 10:59 ` fweimer at redhat dot com 2023-08-22 13:55 ` sam at gentoo dot org 2023-09-11 7:27 ` fweimer at redhat dot com [this message] 2023-09-11 20:04 ` sam at gentoo dot org 2023-09-11 20:04 ` sam at gentoo dot org 2023-09-19 7:36 ` fweimer at redhat dot com 2023-10-06 9:09 ` fweimer at redhat dot com 2023-10-06 9:09 ` fweimer at redhat dot com 2023-10-18 14:29 ` fweimer at redhat dot com 2023-10-18 14:38 ` fweimer at redhat dot com 2023-10-18 14:38 ` 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-30785-131-09mRkc9S8g@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: linkBe 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).