[Bug nptl/26955] pthread_key_create may return duplicates if libpthread.so loaded more than once

["carlos at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=26955

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
I don't think there is anything wrong with the observed results, for RTLD_LOCAL
you get what the API said it does, and for dlmopen we could do better, but what
is there today is an expression of the current semantics.

There are two issues:

(a) Using RTLD_LOCAL to load a distinct copy of the same library.
- You have reloaded a copy of the implementation into it's own scope.
- There is no guarantee that this implementation needs to coordinate with the
currently loaded version.
- There is no guarantee that they are even compatible.
- I don't think this use case is particularly relevant.
- If you think this is relevant, please expand on this.

(b) Using dlmopen to load a distinct copy of the same library.
- The purpose of dlmopen is exactly to isolate libraries and so a dlmopen
version of libpthread should not interact with anything else and that means
some APIs will be decoupled in this way.
- In the most recent discussions around improving dlmopen we have discussed two
modes of operation:
(b.1) Isolation from the "C implementation" and up.
-- This is what the stackoverflow poster wants, but isn't implemented (until we
fix and commit Vivek's patches).
(b.2) Complete isolation.
-- This is what is implemented today, and it's dangerous to take anything but
very simple objects across the dlmopen boundary.
- In the case of (b.1) we extend the C implementation into every namespace
created by dlmopen and provide consistent APIs for the subsequently loaded
libraries. Every namespace though would start with the dynamic loader and the C
library (which will soon include libpthread as we migrate everything to a
single library).
- In the case of (b.2), and audit modules want this, you don't proxy any global
objects into the namespace, you get full isolation, but once you enter the
namespace you never exit it (audit modules are always run in their own
namespace and can't share data outside of them), and it's unsafe to share
across the namespace boundaries.

In summary:
- Using RTLD_LOCAL to load a second copy of the C library that works but
doesn't quite coordinate with the first C library is not an interesting problem
to solve.
- Using dlmopen and having coordination issues is something that would be
interesting to solve, and we have some patches for that:
https://sourceware.org/legacy-ml/libc-alpha/2019-08/msg00442.html

Does that give you some direction?

-- 
You are receiving this mail because:
You are on the CC list for the bug.