These days, glibc implements _exit() as a wrapper around
exit_group(2). (When seccomp was originally introduced, this was
not the case.) Give the reader a clue that, despite what glibc is
doing, what SECCOMP_SET_MODE_STRICT permits is the true _exit(2)
system call, and not exit_group(2).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It is unfortunate that this discourages this use of chroot(2)
without pointing out alternative solutions - for example,
OpenSSH and vsftpd both still rely on chroot(2) for security.
Bind mounts should theoretically be usable as a replacement, but
currently, they have a similar problem (CVE-2015-2925) that hasn't
been fixed in ~6 months, so I'd rather not add it to the manpage
as a solution before a fix lands.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Many years ago, text was added to the page saying that it is
implementation-dependent whether stdio streams are flushed and
whether temporary are removed. In part, this change appears to
be because POSIX.1-2001 added text related to this point.
However, that seems to have been an error in POSIX, and the
text was subsequently removed for POSIX.1-2008. See
https://collaboration.opengroup.org/austin/interps/documents/9984/AI-085.txt
Austin Group Interpretation reference 1003.1-2001 #085
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think utimensat() and futimens() are thread-safe.
But, there are not markings of utimensat() and futimens() in glibc
document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think eventfd() is thread-safe. But, there
is not marking of eventfd() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think clock_getres(), clock_gettime() and
clock_settime() are thread-safe. But, there are not markings of
clock_getres(), clock_gettime() and clock_settime() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
David Rientjes has noticed that MAP_POPULATE wording might promise
much more than the kernel actually provides and intend to provide.
The primary usage of the flag is to pre-fault the range. There is
no guarantee that no major faults will happen later on. The pages
might have been reclaimed by the time the process tries to access
them.
Reviewed-by: Eric B Munson <emunson@akamai.com>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
MAP_LOCKED had a subtly different semantic from mmap(2)+mlock(2)
since it has been introduced.
mlock(2) fails if the memory range cannot get populated to
guarantee that no future major faults will happen on the range.
mmap(MAP_LOCKED) on the other hand silently succeeds even if
the range was populated only partially.
Fixing this subtle difference in the kernel is rather awkward
because the memory population happens after mm locks have been
dropped and so the cleanup before returning failure (munlock)
could operate on something else than the originally mapped area.
E.g. speculative userspace page fault handler catching SEGV and
doing mmap(fault_addr, MAP_FIXED|MAP_LOCKED) might discard portion
of a racing mmap and lead to lost data. Although it is not clear
whether such a usage would be valid, mmap page doesn't explicitly
describe requirements for threaded applications so we cannot
exclude this possibility.
This patch makes the semantic of MAP_LOCKED explicit and suggests
using mmap + mlock as the only way to guarantee no later major
page faults.
Reviewed-by: Eric B Munson <emunson@akamai.com>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
The marking of functions in glibc is:
- sigaltstack: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
The marking of functions in glibc is:
- getrusage: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think prlimit() is thread-safe. But, there
is not marking of prlimit() in glibc document.
getrlimit() and setrlimit() match glibc markings.
- getrlimit: MT-Safe
- setrlimit: MT-Safe
- prlimit: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The text on mixinf I/O syscalls and stdio is a general point
of behavior. It's not a bug as such.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk