From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-68821-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 39381 invoked by alias); 13 Apr 2016 13:26:48 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 39343 invoked by uid 89); 13 Apr 2016 13:26:47 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=inclined, restoring, his, tips
X-HELO: mail-yw0-f181.google.com
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:to:from:subject:message-id:date:user-agent
         :mime-version:content-transfer-encoding;
        bh=0KlvswHKuTI2ZqZg0nHgsTf78xYuNNVCqIjZ4pr8tQo=;
        b=R1K7htjEUH+OWFkvU7vpI5jkSX9eDUIv9InPcsPkrHwWUXddAuv9ECPCbGZ9AQdG7B
         qtwyddRUQUc9OBNaomeBf91QIJgx9jT8kt8ttQWUJxLJ5xjL7xgdLrSZ8HDg3+abZsj2
         Iy1hzhubLi8/0BwpPH9WZn9MQSriKBsOAbQinlX0CQLhaHEbEout1ercHGMeRCE3Evus
         p+G1ebzLunqoIBmDmGWPajocKZNilpTSaNYktfVdLvQHOqZBkBMVFA9VM8pBWuIDq1f3
         NbSuadXgUrnQw3AMIOTT2PHbNaolo6BtMe7UKRL20BHYcapdeJqSVNjI0FU1tcs2J74L
         w5Dg==
X-Gm-Message-State: AOPr4FWBISZBUTF7NwWPTXjAzWTwnNnvrUp3iv4OIbu0B+0J7T08ua1UmR+PHw3Vyo1dJlfQ
X-Received: by 10.129.46.69 with SMTP id u66mr4721890ywu.143.1460553995101;
        Wed, 13 Apr 2016 06:26:35 -0700 (PDT)
To: GNU C Library <libc-alpha@sourceware.org>
From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Subject: RFC: clone with CLONE_VM behavior
Message-ID: <570E4908.4030506@linaro.org>
Date: Wed, 13 Apr 2016 13:26:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-SW-Source: 2016-04/txt/msg00307.txt.bz2

Hi all,

Szabolcs has brought to my attention that the new posix_spawn is showing
some issue on his aarch64 [1], but it is not limited to aarch64.

The problem is due the fact GLIBC clone implementation resets both
THREAD_SELF pid and tid when CLONE_VM is specified. This leads to
inconsistency since the value is not restored back in parent and
thus INVALID_TD_P and INVALID_NOT_TERMINATED_TD_P (used in pthread
implementations) will bail with an error handler.

Previous posix_spawn uses vfork which only interferes with THREAD_SELF
pid field by negating it before the syscall and restoring the value
after it.

I am trying to came up with the best solution for this, since both
pid and tid is used in both pthread_{join,cancel} and also on raise
(which also have another issue somewhat related [2]) and I am inclined
to just remove the CLONE_VM changes to pid/tid fields in the syscall
itself and moving it to START_THREAD_DEFN instead.

Any better ideas, tips, advices?

[1] https://sourceware.org/ml/libc-alpha/2016-04/msg00274.html
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=15368