Date: Thu, 27 May 2021 11:29:55 -0400 From: Rich Felker <dalias@...c.org> To: libc-coord@...ts.openwall.com Subject: Re: Thread properties API On Fri, May 21, 2021 at 06:06:33PM +0200, Florian Weimer wrote: > In glibc, we have a historic gap when it comes to access to per-thread > data that may contain application data. Such functionality is required > to support memory leak detectors and conservative garbage collectors > that need to discover pointer values in TLS data. The sanitizers > currently hard-code glibc implementation details (that are not really > unchanging in practice), and we want to switch to a defined interface > eventually. > > We provide some access to per-thread data using libthread_db, but that > functionality is incomplete in several ways and not readily consumable > inside a process. > > There is a completely different proposal here: > > <https://sourceware.org/glibc/wiki/ThreadPropertiesAPI> > > The interfaces that follow below avoid callback functions that must be > invoked with internal locks held because that is prone to lead to > deadlocks. They also avoid encoding a specific, unchanging layout for > the static TLS area (which can be extended, but not moved) or internal > pthread_setspecific tables, or whether any such per-thread data > structures are allocated by malloc. > > I'd appreciate comments on this proposal. It's very early and I'm not > entirely convinced yet that it is actually implementable. 8-) I'm largely against all of these, on several bases: - They may impose significant implementation constraints that preclude completely reworking the implementation strategy, as has been necessary several times in the past, and lock out new implementations that want to take different approaches by virtue of having application software come to depend on the new interfaces. For example a highly NUMA oriented implementation may not even *have* a consistent idea of "all existent threads". And imposing that POSIX TSD lives in blocks of unadorned pointers precludes all sorts of hardening. - The retention interfaces break the model that *any* use of a pthread_t identifier past its lifetime is UB, by defining interfaces that completely override the POSIX pthread_t lifetime rules. - Some if not all of the functionality can be achieved in less-invasive ways using existing interfaces. For example you can iterate TLS with dl_iterate_phdr and __tls_get_addr. POSIX TSD is possibly messier especially if you wanted AS-safety (not possible) but I don't know what the constraints are. It looks to me like these are just designed around facilitating sanitizers or fragile GC implementations continuing to do stuff they want to do, but with a stable public interface to internals rather than poking at internals directly. However most if not all of these things could be done by *reducing* the number of implementation-detail assumptions on the sanitizer runtime side rather than just giving them an officially supported window into these details. I've looked at the proposal on the wiki before, and the majority of this struck me as not well motivated. In other words, I haven't seen an attempt to distill out what the tools in question actually need to do their jobs, which of these things are fundamental vs a consequence of their current implementation choices. Some of the needs seem to be a consequence of glibc-specific implementation choices (like lazy TLS allocation or thread stack caching and reuse) and the need to handle them is very glibc-specific, but perhaps admits solutions that aren't. I know some of these things were discussed in #musl and I'll look for notes that might help. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.