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>
When mremap() is used to move or expand a mapping that is locked
with mlock() or equivalent it will attempt to populate the new
area. However, like mmap(MAP_LOCKED), mremap() will not fail if
the area cannot be populated. Also like mmap(MAP_LOCKED) this
might come as a surprise to users and should be noted.
Signed-off-by: Eric B Munson <emunson@akamai.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: David Rientjes <rientjes@google.com>
Cc: linux-man@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add detail information for threads-max.
The checks for minimum and maximum values exist since kernel 4.1.
https://lkml.org/lkml/2015/3/15/96
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
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>
Improve description of tcp_ecn, fix the RFC number and it's
not a boolean anymore since long time, and add a description
for tcp_ecn_fallback.
See also kernel doc under Documentation/networking/ip-sysctl.txt
on tcp_ecn and tcp_ecn_fallback.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
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>
An earlier edit mentioned O_TTY_INIT as a file creation flag.
That's true, according POSIX, but Linux does not implement
this flag, so remove mention of it.
Reported-by: David Drysdale <drysdale@google.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Gabriel F. T. Gomes