Re: Caching of PID/TID after fork

[Rich Felker <dalias at libc dot org>]

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