From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16317 invoked by alias); 6 Oct 2016 18:32:40 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 16270 invoked by uid 89); 6 Oct 2016 18:32:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:2352, incur X-HELO: mail-ua0-f179.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=TMW/F6Yj/1Rfso7Zsz9rUnz5aYlM9qmUqBY9cykmUBA=; b=KGtxbF18Wvn2ZD7FTICekIFCHdabi2uS6upsjIn+SN6QV34yJIkvW0TH4etcJSSMc3 InoEv3Fl8H5NqiER6dKSUVgOdq6C0ZIJY/EbRfYnC1I2KmTG+2f2bqxJhjDWjrVxxP2N +1kXnl6Qxj9e1LJFRxDVrCHNWm4DvM6eAoOo6soV0UAVRHhbWZ1ET4j5LdTWF7awCSLt HArj/1pk6fLMtrBzD84Z/KhqePdlmzaf+pvj/8OisxNJ81z59Ea1f2f7KuV/GdFuZ2+q TowfaA7I/ueA8ivK5llcLuea6Xml/6Ylco9BccGjsUND4JKTPFisVa+JcWp9YLa8pWyh 1GHA== X-Gm-Message-State: AA6/9RnjdegB6nRP/qi8SXfIKRvlaWqyMU8xUzku3SMy0ncOqudrvKC4nmsC4HWZyuan93El X-Received: by 10.176.83.218 with SMTP id l26mr11718496uaa.39.1475778747503; Thu, 06 Oct 2016 11:32:27 -0700 (PDT) Subject: Re: Caching of PID/TID after fork To: libc-alpha@sourceware.org References: From: Adhemerval Zanella Message-ID: <178a59d3-9fed-9235-b933-1064fc454cc8@linaro.org> Date: Thu, 06 Oct 2016 18:32:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2016-10/txt/msg00147.txt.bz2 Besides the clone(CLONE_VM) issues, another one related to pid/tid caching was BZ#15368 [1]. The problem of providing a clone syscal that do not cache pid/tid is current mutex, rwlocks, and some other implementations (pthread_clock_gettime, etc.) relies on correct pid/tid information. So if it is a potential source of issues if the exported clone do not provide the correct semantics. Also, providing a glibc own symbol to update the tid/pid is messy: it would be an internal implementation detail which in theory application should not have access to, it might add some synchronization issues (what happens if you try to force update after a mutex operation with default wrong value?), and it also might be tricky to add a compatibility symbol in case of change how tid/pid internally works. Another possible solution was to get rid of the caching entirely, but it might incur in some performance issues (each tid/pid get will trigger another syscall). We can minimize the performance issue by adding a vdso implementation of getpid/gettid, but some architectures and configuration will still not benefit from it (also, afaik current x86 kernel do not provide getpid/gettid as vsyscall neither as vdso and recall that for glibc we deprecated vsyscall use). Another possibility is to use another thread unique identifier as the owner instead of tid (maybe a hash of pthread_t to fit on a int). By removing this requirement I think it is feasible to get rid of caching. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=15368 On 06/10/2016 14:03, Robert Święcki wrote: > 3. Provide clone() wrapper, which doesn't impose additional > restrictions over kernel's __NR_clone and which updates the TID/PID > cache. > > 2016-10-06 18:33 GMT+02:00 Paul Pluzhnikov : >> On Thu, Oct 6, 2016 at 9:13 AM, Robert Święcki wrote: >> >>> This has probably been debated a lot of times in the past, but... >> >> We should probably mention that caching of PID has caused bugs in the past, e.g. >> https://sourceware.org/bugzilla/show_bug.cgi?id=19957 >> https://sourceware.org/ml/libc-alpha/2006-07/msg00123.html >> >> There is also >> http://www.eglibc.org/archives/issues/msg00061.html >> http://yarchive.net/comp/linux/getpid_caching.html >> >> -- >> Paul Pluzhnikov > > >