[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210527152954.GJ2546@brightrain.aerifal.cx>
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.
