From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73515 invoked by alias); 6 Oct 2016 17:26:38 -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 73497 invoked by uid 89); 6 Oct 2016 17:26:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 spammy=she X-HELO: brightrain.aerifal.cx Date: Thu, 06 Oct 2016 17:26:00 -0000 From: Rich Felker To: Robert =?utf-8?B?xZp3acSZY2tp?= Cc: libc-alpha@sourceware.org Subject: Re: Caching of PID/TID after fork Message-ID: <20161006172631.GO19318@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2016-10/txt/msg00143.txt.bz2 On Thu, Oct 06, 2016 at 06:13:41PM +0200, Robert Święcki wrote: > Hi, > > This has probably been debated a lot of times in the past, but... > > A lot of tool these days create Linux namespaces, using clone(). Using > glibc's clone() is not the best option, because e.g. it requires stack > pointer, (and fails with some error if it's NULL), while Linux kernel > will happily reuse the current SP (no need to write additional code to > deal with that). So, glibc's clone() adds imposed additional > restrictions wrt kernel. > > And, after that getpid() will return old PID/TID. > > It seems that currently Linux supports getpid() via vsyscall (fast) on > x86/64. Would you consider changing getpid() to be a wrapper to > syscall(__NR_getpid)? > > One could say that if somebody uses syscall(__NR_clone) she/he should > be using syscall(__NR_getpid) as well, but in case of software > libraries, which might be preparing namespaces, the caller of the lib > might know nothing about the exact method used to create a new > process. > > Thefore I'd like to ask for one of the following solutions: > > 1. Don't cache PID/TID > > 2. Provide some kind of symbol, which would force for TID/PID to be > reloaded in glibc. There's an easy solution that works with existing versions of glibc (and other libcs) with no new symbol or new symbol version dependency: call the libc clone() function with a tiny dummy stack and a function which does nothing but longjmp out to the caller. Rich