Quoting Florian:
This does not work because libm.so can be a linker script:
handle = dlopen("libm.so", RTLD_LAZY);
The proper way to do this is to include <gnu/lib-names.h>
and use LIBM_SO.
See https://bugzilla.kernel.org/show_bug.cgi?id=108821
Reported-by: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As noted by Florian Weimer:
The manual daemon(3) manual page talks about the "calling
process's current working directory". I think this is
misleading because the function exits the calling process
before changing the current directory.
Reported-by: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
GNU C Library commit 1747fcda4902a3b46183d93fb16ed9b436b2608b
extends the priorities that can be set to the Program Priority
Register (PPR), with the functions: __ppc_set_ppr_very_low(3)
and __ppc_set_ppr_med_high(3).
Signed-off-by: Gabriel F. T. Gomes <gftg@linux.vnet.ibm.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As stated in the SYNOPSIS, since glibc 2.10 this function is also
declared by the relevant X/Open and POSIX macros.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
When the glibc implementation of posix_fallocate detects
that the underlying filesystem does not support fallocate()
it uses an emulation function to attempt to allocate the
space requested. The most common case is calling
posix_fallocatei() for a file that is on NFS where the
NFS server is not new enough to support the recent fallocate
extensions. This emulation has various serious caveats that
must be understood in order to use posix_fallocate robustly
on all filesystems. The change documents the caveats in the
glibc implementation.
Lastly, we expand the meaning of EINVAL to match POSIX
2013 (Issue 7). If the underlying filesystem doesn't support
posix_fallocate()i, the implementation can return EINVAL, but
glibc does not do this, it emulates the operation instead.
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
The marking of functions in glibc is:
- mallinfo: MT-Unsafe init const:mallopt
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think
* getspnam(),
* getspent(),
* setspent(),
* endspent(),
* getspent_r(),
* fgetspent(),
* sgetspent(),
are not thread-safe. And
* putspent(),
* getspnam_r(),
* sgetspent_r(),
* lckpwdf(),
* ulckpwdf(),
* fgetspent_r(),
are thread-safe. But, there are not
markings of them in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
marking of function in glibc is:
- fgetgrent: MT-Unsafe race:fpwent
ps: We think race:fpwent in glibc maybe hard for users to understand,
and have sent a patch to the GNU libc community for changing it to
race:fgetpwent, however, something about the copyright impeded the progress.
Here we mark it "race:fgetpwent", so there is a little different.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
marking of function in glibc is:
- fgetgrent: MT-Unsafe race:fgrent
ps: We think race:fgrent in glibc maybe hard for users to understand,
and have sent a patch to the GNU libc community for changing it to
race:fgetgrent, however, something about the copyright impeded the progress.
Here we mark it "race:fgetgrent", so there is a little different.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In 2013 I brought up the discussion if M_ARENA_MAX and M_ARENA_TEST
were public parameters:
https://sourceware.org/ml/libc-alpha/2013-03/msg00376.html
Consensus among Siddhesh and myself was that they should be
public, and in fact they were already in the public header.
Therefore there may already be applications uses these constants
and expecting them to work. At best we could limit mallopt()'s
acceptance of the options, but that seems like a bad solution
that could lead to unexpected behavior for user applications.
A quick google search shows that there are packages relying on
these constants to tune the glibc malloc implementation.
Since glibc 2.10 the M_ARENA_TEST and M_ARENA_MAX features
have been part of the public interface with
--enable-experimental-malloc.
Since glibc 2.15 the experimental allocator has been on by default
and M_ARENA_TEST and M_ARENA_MAX have been more broadly used.
There are environment variables, without trailing underscore, that
can also be used to adjust these values at runtime i.e.
MALLOC_ARENA_MAX, and MALLOC_ARENA_TEST.
This change describes these two options in the mallopt(3) man page
along with their environment variables.
Tested with glibc master on x86_64 to verify it works as expected.
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, we think
* dlinfo()
is thread-safe. But, there are not markings of it in
glibc document.
[mtk: split out of a larger dlopen() patch]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Jakub Wilk