From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41046 invoked by alias); 24 Jan 2018 20:06:27 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 41032 invoked by uid 89); 24 Jan 2018 20:06:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=observable X-HELO: mail-qt0-f173.google.com Received: from mail-qt0-f173.google.com (HELO mail-qt0-f173.google.com) (209.85.216.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 Jan 2018 20:06:25 +0000 Received: by mail-qt0-f173.google.com with SMTP id g14so13586045qti.2 for ; Wed, 24 Jan 2018 12:06:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=zBZQlVDNiTi1jiN7AcouIedIkiGzcdHsxMH3QP6b3hY=; b=ukHB547bdlGlmxzumAeWZiitLq+GVcpRpPVNsEvUMm4c7NlQFfrJtCeMbYlrvyXeIB GP0/hSeB8fNF4SjnJsX7OVRHXJAm7eBisySCdyDgWpw1hY3HQvsMB6wmlceEbWShIgXU S8cRqDzgtkaQOfRue6+DKewTnXcvS31M4LMYXUxw8Bi67tKD7ymqn5MWb9He+/mj+wur tSyFNOeD+MEL9Idj5mBU+A7WGP+Qb2IfptXgKBzFUg/DRG2Dl8J5Vs4M6aPDnRdYtJTV Gy9Ejg7/IkZmb475wu5ocU3nrA0H0SfUnKi8fVKukv+jWmQuIse1E9mG+vgq0HmjnLsD VNSw== X-Gm-Message-State: AKwxyte/HCvRY2cyii4jke9pslTkNvROEt2cwf3OU+rdMqwBbA8HAyv+ FMIkm312WbnvgVdjG8FSNcqnHw== X-Google-Smtp-Source: AH8x226iBFaQClKmnEq+4BvZsUDu045/Z7o+gGUjFlu2+f0Dwbl+2i2zCIq4FNkG1Mv4P1jKvvPAZQ== X-Received: by 10.55.177.131 with SMTP id a125mr331446qkf.101.1516824383960; Wed, 24 Jan 2018 12:06:23 -0800 (PST) Received: from [192.168.1.15] (198.sub-174-215-6.myvzw.com. [174.215.6.198]) by smtp.gmail.com with ESMTPSA id d201sm739955qke.69.2018.01.24.12.06.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jan 2018 12:06:22 -0800 (PST) Subject: Re: A possible libc/dlmopen/pthreads bug To: Szabolcs Nagy , Adhemerval Zanella , libc-help@sourceware.org Cc: nd@arm.com References: <41b64265-397f-1ead-dd79-50052b2d19af@arm.com> <9ff5882f-879f-3069-1ea0-268e2c5e6ac0@linaro.org> <5b706ebb-bc44-d7c8-442b-21ab979e2c81@arm.com> From: Carlos O'Donell Message-ID: Date: Wed, 24 Jan 2018 20:06:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5b706ebb-bc44-d7c8-442b-21ab979e2c81@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00019.txt.bz2 On 01/24/2018 11:34 AM, Szabolcs Nagy wrote: > On 24/01/18 17:25, Adhemerval Zanella wrote: >> In fact I think Vivek examples of running process with two different libcs >> are working mainly because the different glibc define and access the shared >> resources in same manner.  I bet it will break the moment we change some >> state internal layout or semantic (for instance the __stack_user struct size). > > even if the two libc has same code and same layout for > internal data structures it is completely broken: > there are two copies of the libc global data section > with inconsistent content. > > if printf called twice via different libcs they get > buffered independently, but write to the same fd, so > the observable effect on stdout can be out of order, > fflush on namespace boundary does not help since the > locks of one libc don't work on the other, the writes > can happen concurrently. > > setxid has to coordinate with all threads via signals, > even with the ones created by the other libc. > > same for atfork handlers: the handlers of the other > libc has to run too. > > same of tls/tsd dtors: at thread exit the other libc > tls/tsd data should be freed too. > > the dynamic loader + libc + libpthread needs to have > one unique instance or some apis won't work across > all instances. Correct. All of these things need to be shared to fix dlmopen in the "simple" use case e.g. a shared glibc, but everything else isolated. The "isolation" use case in which a potentially new dynamic loader / libc is loaded into the dlmopen namespace will require a stable API between the loaders to coordinate such issues, and I'm not entirely sure we want that. So I would not start by implementing this higher level of isolation. For example such isolation may mean you must check API compat level and may be rejected such that all you can do is run dlmopen, but not call into the namespace for compat reasons (letting the namespace run on it's own with constructors that create threads that only live in the namespace). For now I'm happy with the "simple" use case of a matching C runtime implementation in both the outer and inner namespaces. However, keep in mind that the problems you face with the C runtime will appear again with higher level libraries. This concept of "shim" libraries will only work for some limited set of libraries that are relatively stateless (and as you see glibc is not). -- Cheers, Carlos.