From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8B16F3851C01; Thu, 26 Nov 2020 19:56:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8B16F3851C01 From: "carlos at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug nptl/26955] pthread_key_create may return duplicates if libpthread.so loaded more than once Date: Thu, 26 Nov 2020 19:56:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: 2.34 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: carlos at redhat dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 19:56:54 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26955 Carlos O'Donell changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |carlos at redhat dot com --- Comment #1 from Carlos O'Donell --- I don't think there is anything wrong with the observed results, for RTLD_L= OCAL 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 t= he 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 (unti= l we fix and commit Vivek's patches). (b.2) Complete isolation. -- This is what is implemented today, and it's dangerous to take anything b= ut 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 t= he 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 gl= obal 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 pro= blem 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? --=20 You are receiving this mail because: You are on the CC list for the bug.=