Caching of PID/TID after fork

[Robert Święcki <robert at swiecki dot net>]

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.

-- 
Robert Święcki