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>
Michael Kerrisk