Since glibc 2.25 the PID cache is removed.
Rationale given in the release notes:
https://sourceware.org/glibc/wiki/Release/2.25#pid_cache_removal
~~~
3.2.3. Calls to getpid are no longer cached
The PID cache used by glibc has been removed. In certain scenarios
the cache was not 100% reliable and because of that it was deemed
safer to remove the cache than to potentially return a wrong
answer.
Applications performing getpid() calls in a loop will see the
worst case performance degradation as the library call will
perform a system call at each invocation. Such application uses
were known to exist at least in OpenSSL (fork()-based PRNG
invalidation), but supporting the performance of that specific
invalidation mechanism was not judged to have sufficient value
against immediate and long-term benefits of removing the cache.
Functional reasons exist for the PID cache removal including
problems with PID namespaces, interoperability with raw system
calls (BZ#17214, Chrome: Issue 800183004), and improvements to
spawn (BZ#19957). Performance is actually increased in
pthread_create() with the removal of the cache since the
implementation no longer needs to perform an invalidation step.
Applications performing getpid() in a loop that need to do some
level of fork()-based invalidation can instead use
pthread_atfork() to register handlers to handle the invalidation.
There is work-in-progress to make pthread_atfork() available to
applications that do not link against libpthread.so (Provide
pthread_atfork() without libpthread.so).
Other kinds of invalidation are not supported and the glibc
community will actively look at a kernel assisted mechanism for
state management across fork(), vfork(), clone() and other
interfaces which can benefit from such semantics. It is the same
type of solution required for crypto PRNG reset across such API
calls.
~~~
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
See https://bugzilla.kernel.org/show_bug.cgi?id=196319
[mtk: confirmed from review of draft of C90 standard]
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
First clarify that the process cannot catch this SIGSYS signal.
While the text currently says that, it's easy (IMO) to read
ambiguously and that it's referring to default behavior (no
handler -> process exits).
Then add details regarding coredump behavior. Before Linux 4.11,
there was no way to get coredumps from such crashes. Now we can
at least get crashes from single threaded processes.
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
ld.so.8: Expand DT_RUNPATH details.
Every 3 years we get asked why DT_RUNPATH doesn't work like DT_RPATH.
The most recent question was here:
https://www.sourceware.org/ml/libc-help/2017-06/msg00013.html
We need to expand the description of DT_RUNPATH to cover this situation
and explain that the DT_RUNPATH entries apply only to the immediate
DT_NEEDED, not that of another, say dlopen'd child object.
Applies to master.
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In glibc we just finished a round of purging 'struct ucontext'
which is not in the POSIX reserved namespace of *_t tags. This has
some consequences to applications using the non-standard struct
ucontext:
https://sourceware.org/glibc/wiki/Release/2.26#Removal_of_.27struct_ucontext.27
but it also fixes a namespace conformance issue which is always a
longterm pain for large portable programs.
It was noted by Peter Maydell
(https://sourceware.org/bugzilla/show_bug.cgi?id=21457) that the
linux man pages still had references to 'struct ucontext' but only
in the form of an exemplar structure.
The patch fixes the exemplar to match what is in glibc
and therefore it won't ever suggest users can use 'struct
ucontext'.
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
There is a POSIX_FADV_NOREUSE for posix_fadvise(),
but no POSIX_MADV_NOREUSE for any API in POSIX.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
POSIX_FADV_NOREUSE is documented for posix_fadvise, and a
corresponding POSIX_MADV_NOREUSE flag is not specified by POSIX.
Thanks to Marc Lehmann <debian-reportbug@plan9.de>
See https://bugs.debian.org/865699
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Make the discussion clearer, and add a few details.
Also, fix the problem report from Pavel Tikhomirov
who noted that the man page falsely said that errno
is not changed on a successful return.
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=195955
Reported-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk