Michael Kerrisk [Thu, 15 Sep 2016 16:39:57 +0000 (18:39 +0200)]
clone.2: EINVAL is generated by glibc wrapper for NULL 'fn' or 'child_stack'
Clarify that this error is produced by the wrapper function, not
the underlying system call. In particular, the point is that the
raw system call can accommodate a NULL pointer for 'child_stack'.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Namhyung Kim [Sat, 10 Sep 2016 02:19:06 +0000 (11:19 +0900)]
proc.5: Add description of CLEAR_REFS_MM_HIWATER_RSS
The Linux kernel commit 695f05593693 ("fs/proc/task_mmu.c: add
user-space support for resetting mm->hiwater_rss (peak RSS)") added a
way to reset peak RSS of a process but missed to update manpage.
Cc: Petr Cermak <petrcermak@chromium.org> Acked-by: Petr Cermak <petrcermak@chromium.org> Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Michael Kerrisk [Mon, 12 Sep 2016 18:25:44 +0000 (19:25 +0100)]
raw.7: Clarify user namespace requirements for CAP_NET_RAW
Also remove mention of UID 0 as a method or creating
a raw socket. As far as I can tell from reading the
kernel source (net/ipv4/af_inet.c), this is not true.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Sun, 26 Jun 2016 13:16:32 +0000 (15:16 +0200)]
killpg.2: Refer reader to kill(2) for signal permission rules
Rather than repeating details here, refer the reader to kill(2)
(so that the rules are in a canonical location, and need only
be edited in one place for future changes--see next commit).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Sun, 26 Jun 2016 13:06:07 +0000 (15:06 +0200)]
fcntl.2: Note an important detail of F_SETOWN permission rules for signals
F_SETOWN records the caller's credentials at the time of
the fcntl() call, and it is these saved credentials that
are used for subsequent permission checks.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Sun, 26 Jun 2016 12:59:33 +0000 (14:59 +0200)]
socket.7: SIOCSPGRP: refer to fcntl(2) F_SETOWN for correct permission rules
The permission rules described for SIOCCPGRP are wrong. Rather
than repeat the rules here, just refer the reader to fcntl(2),
where the rules are described for F_SETOWN.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Sun, 11 Sep 2016 10:22:08 +0000 (11:22 +0100)]
ld.so.8: Remove discussion of environment variables understood by libc5
libc5 disappeared long ago, so cease cluttering up this page
with those ancient details. Thus, remove discussion of the
following environment variables: LD_AOUT_LIBRARY_PATH,
LD_AOUT_PRELOAD, LD_KEEPDIR, LD_NOWARN, and LDD_ARGV0.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Sun, 4 Sep 2016 04:44:47 +0000 (16:44 +1200)]
rename.2: Minor wording fix
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>
Michael Kerrisk [Sat, 3 Sep 2016 16:10:09 +0000 (04:10 +1200)]
rename.2: Relocate some text text
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>
Michael Kerrisk [Sat, 3 Sep 2016 15:53:28 +0000 (03:53 +1200)]
rename.2: Clarify that ERRORS may cause rename to fail (not to be nonatomic)
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>
mlock.2: Document that fork() after mlock() may be a bad idea in a RT process
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>
Michael Kerrisk [Mon, 29 Aug 2016 19:01:12 +0000 (07:01 +1200)]
stat.2: Tweak discussion of 'st_size' for /proc and /sys files
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>
projects / thirdparty / man-pages.git / log
