[mtk: The raw system calls use "unsigned int", but the glibc
wrappers have "int" for the 'flags' argument.]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
People seem to be using "cf." ("confere"), which means "compare",
to mean "see" instead, for which the Latin abbreviation would be
"q.v." ("quod vide" -> "which see").
In some cases "cf." might actually be the correct term but it's
still not clear what specific aspects of a function/system call
one is supposed to be comparing.
I left one use in place in hope of obtaining clarification,
because it looks like it might be useful there, if contextualized.
Migrate these uses to English and add them to the list of
abbreviations to be avoided.
If the patch to vfork(2) is not accepted, then the cf. still needs
an \& after it because it is at the end of the line but not the
end of a sentence.
Signed-off-by: G. Branden Robinson <g.branden.robinson@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It's more logical to use lstat() in the example code,
since one can then experiment with sybolic links, and
also the S_IFLNK case can also occur.
Reported-by: Richard Knutsson <richard.knutsson@abelko.se>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Userfaultfd feature UFFD_FEATURE_SIGBUS was merged recently and
should be available in the Linux 4.14 release. This patch is for
the man page changes documenting this API.
Documents the following commit:
commit 2d6d6f5a09a96cc1fec7ed992b825e05f64cb50e
Author: Prakash Sangappa <prakash.sangappa@oracle.com>
Date: Wed Sep 6 16:23:39 2017 -0700
mm: userfaultfd: add feature to request for a signal delivery
Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
Reviewed-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Signed-off-by: Prakash Sangappa <prakash.sangappa@oracle.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
When referring to the architecture, consistently use "x86-64",
not "x86_64". Hitherto, there was a mixture of usages, with
"x86-64" predominant.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Combine two redundant paragraphs (one of which I recently
added) describing child_stack==NULL for the raw system call.
Also, make sure this text is in a more obvious place than
its previous location.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
At the current man page for shmat(2)[1], there is no mentioning
whether the returned memory address of shmat(2) will be page size
aligned or not. As that is quite important to many applications(e.g.,
those that use locks heavily and would like to avoid some locks by
some atomic guarantees provided by the CPU), it would be great to
specify that for Linux.
I walked down the current implementation of shmat(2) in the latest
kernel src and found that shmat(2) does return a page size aligned
memory address:
SYSCALL_DEFINE3(shmat, int, shmid, char __user *, shmaddr, int, shmflg)
-> do_shmat(...)
-> do_mmap_pgoff(...)
-> do_mmap(...)
-> get_unmapped_area(...)
-> get_area(...) -> offset_in_page(addr)
there is a `offset_in_page(addr)' assertion at the end and if that is
true a -EINVAL would be returned, by which we can be sure that
shmat(2) will return a page size aligned memory address on success[2].
[1]: http://man7.org/linux/man-pages/man2/shmat.2.html
[2]: there is also a `offset_in_page(2)' in get_unmapped_area(...),
but that doesn't lead to -EINVAL...I am not sure whether the logic of
that code is right.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Expand and rework the text a little, in particular adding
a reference to sigreturn(2) as a source of further
information about the ucontext argument.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk