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>
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>
Mike Frysinger