The meaning of "when overwriting" is not clear. I believe what is
meant is that when an existing 'newpath' is replaced. However, we
can convey that meaning by eliding this text with the preceding
paragraph, so this patch does that.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Relocate text noting that there may be a window when 'oldpath' and
'newpath' refer to the same file. Logically, this text appears to
belong near the text noting that an existing 'newpath' will be
atomically replaced. (In ancient versions of the page, these two
pieces of text were closer together.)
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The existing wording suggests that there are ERRORS that may cause
the operation to be nonatomic. The point is of course that there
are various restrictions on rename operations that may cause the
operation to fail.
Reported-by: Tim Savannah <kata198@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
fork() will remove the write PTE bit from the page table on each
VMA which will be copied via COW. As such, the memory is available
but marked read only in the page table and will fault on write
access. This renders the previous mlock() operation almost
useless because in a multithreaded application a realtime thread
may block on mmap_sem while a thread with low priority is holding
the mmap_sem (for instance because it is allocating memory which
needs to be mapped in).
There is actually nothing we can do to mitigate the outcome. We could
add a warning to the kernel for people that are not yet aware of the
updated documentation.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
As Mats points out, there appear to be no (or almost no) files
under /proc and /sys for which 'st_size' is meaningful.
(mtk: verified via some scripting over these directories.)
Reported-by: Mats Wichmann <mats@wichmann.us>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Expand and clarify libc/kernel sigset_t differences. Also move
up the signature for rt_sigprocmask, similar to the way this is
done in clone.2.
Due to the history of sigprocmask, there are various notions of
what sigset_t refers to. This attempts to clarify the man page,
by giving the major instances different names:
- sigset_t is the glibc sigset_t (1024 bits)
- kernel_sigset_t is the kernel's sigset_t (64 bits)
- old_kernel_sigset_t is the pre-rt kernel's sigset_t (32 bits)
and explaining their difference in the NOTES. Even though the
sources do not refer to the various sigset_t's by these names, I
think it is important to be explicit, esp since sizeof(sigset_t)
would give an incorrect value for `sigsetsize` if written in a
source file that includes the libc headers.
Lastly, move the note on an incorrect `sigsetsize` causing
EINVAL up to the ERRORS section, so everything is in one place.
If CLONE_FILES is not set, the duplicated FDs nevertheless share
file offset and status flags via the open file description.
Reported-by: Elliott Hughes <enh@google.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Some "magic" symlinks created by the kernel (e.g., those under
/proc and /sys) report 'st_size' as zero. Modify the example
program to handle that possibility.
Reported-by: Ursache Vladimir <f35f22fan@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Avoid closing cfd if it is -1. Initialize buf1_avail, etc. to avoid
uninitialized memory access in the event that accept() fails. Remove
redundant setting of nfds. Fix tabs with spaces.
Do not try to read/write from/to file descriptors once an existing
connection is overwritten, the select() states are stale now.
Avoid writing zero bytes from the buffer and then closing the fd.
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
The man page for res_ninit() incorrectly says that it takes no
parameters, when in fact (and indeed according to the same page
further down) it has to take a res_state parameter.
As Rich Felker comments:
The stdio buffer associated with the fmemopen-obtained FILE,
and the output memory buffer into which it's writing, are
conceptually distinct entities, and there is no reason to
expect reasonable results if you modify the contents of a
setvbuf-associated buffer through other means while it's
associated with a FILE.
See http://stackoverflow.com/questions/38854163/using-rewind-on-a-file-opened-with-fmemopen
Reported-by: Rich Felker <dalias@libc.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The manpage claimed that the offset argument is ignored, and when
I interpreted that as "I don't need to set that register when
doing the syscall", I got failures. I was able to spot two reasons
for that:
What I probably ran into:
At least on x86-64, sys_mmap (in arch/x86/kernel/sys_x86_64.c)
always checks that the offset is page-aligned, even for
MAP_ANONYMOUS.
Another one, could probably trigger on 32-bit x86:
In do_mmap(), there is a check to ensure that pgoff together with
the allocation length won't cause an overflow, even for
MAP_ANONYMOUS.
Document that userspace should pass in zero, since that's
probably what everyone is doing already. (It would also be
possible to describe the constraints on the offset more
carefully, but zero works, and nobody should need to pass in
anything else.)
Signed-off-by: Jann Horn <jann@thejh.net>
HuKeping