This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Caching of PID/TID after fork
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 <ppluzhnikov@google.com>:
>> On Thu, Oct 6, 2016 at 9:13 AM, Robert Święcki <robert@swiecki.net> 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
>
>
>