From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48355 invoked by alias); 24 Jan 2018 20:08:24 -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 48343 invoked by uid 89); 24 Jan 2018 20:08:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=HContent-Transfer-Encoding:8bit X-HELO: mail-qt0-f170.google.com Received: from mail-qt0-f170.google.com (HELO mail-qt0-f170.google.com) (209.85.216.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 Jan 2018 20:08:23 +0000 Received: by mail-qt0-f170.google.com with SMTP id d8so13637925qtm.0 for ; Wed, 24 Jan 2018 12:08:23 -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=5cs2R05FiBVN0aQskACO/xzjc9KPfOv6wDnrQO5MQJo=; b=fKQWcBh+8MXEzXibknnQsOvUcs7jDEh/Fnt5LT4fwGuCKi0W6B6WmWwdVRrgmxKrCK HD/D/u4ASRVPN7pRbiwhucf7Z2LznaJKHkCcftOscZuIpVY217luOx8JwqOmX4/ciMLx LwjsJnYkJJO3k31bDCUueYY+JYaNFZelixw39Yr2IOmWXMnSQ6PXUQt6Bv8mXi83CpjM jt7eAClku4qwiw1k4HGKNNHQ6nhjXuxinZpXmLHAa4gm5EQgvhIEqvI6Rs5L0rXuX5Su iD/8+24RQDTzOxyI+rVaOQdGaQ3Cle3TceDRgT73v5a8rDht8V8MVTA2oBz0vbxn75/H JD7g== X-Gm-Message-State: AKwxytfxOMgNXJoAdDLN7Aot1pcYc6CzSRo3n6pUP8BC2O2ZOa01aqUE 3eHCDawcmjYqi5aqxWdbrA7k16srS3U= X-Google-Smtp-Source: AH8x2273VLWuUI8fY5AbIp1k4ngHD9WnZmA9cjbUNzbwclUcSmgSF3abeQoVq5FBHdcvRpDJFhdRiQ== X-Received: by 10.237.46.39 with SMTP id j36mr11674723qtd.56.1516824501191; Wed, 24 Jan 2018 12:08:21 -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 v20sm2538420qtg.79.2018.01.24.12.08.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jan 2018 12:08:20 -0800 (PST) Subject: Re: A possible libc/dlmopen/pthreads bug To: =?UTF-8?Q?Vivek_Das=c2=a0Mohapatra?= , Adhemerval Zanella Cc: libc-help@sourceware.org References: <41b64265-397f-1ead-dd79-50052b2d19af@arm.com> <9ff5882f-879f-3069-1ea0-268e2c5e6ac0@linaro.org> From: Carlos O'Donell Message-ID: <7f1e8bf7-78d9-7ead-6491-e7acb8aee6a9@redhat.com> Date: Wed, 24 Jan 2018 20:08: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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00020.txt.bz2 On 01/24/2018 09:46 AM, Vivek Das Mohapatra 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). > > A slight correction - we are deliberately using the _same_ libc to > avoid exactly that problem - it's that dlmopen as currently implemented > creates a new mapping of the same libc for the dlmopen namespace. > > I also don't need (or expect) complete isolation of the libc cluster: > If I could, I would share the same mapping of libc & co with the main > link map. This needs fixing, and is one of the reasons that dlmopen is generally not being made available for this use case until we resolve the underlying sharing problem. I'm happy to see patches to make ld.so/glibc shared in all the namespaces. -- Cheers, Carlos.