See Linux commit 56873f43abdcd574b25105867a990f067747b2f4
and Linux commit f074a8f49eb87cde95ac9d040ad5e7ea4f029738
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The current text was confused (mea culpa). No signal is sent to
the init() process. Rather, depending on the 'cmd' given to
reboot(), the 'group_exit_code' value will set to either SIGHUP or
SIGINT, with the effect that one of those signals is reported to
wait() in the parent process.
See https://bugzilla.kernel.org/show_bug.cgi?id=195899
Reported-by: Michał Zegan <webczat_200@poczta.onet.pl>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
hugetlbfs support for memfd_create() was recently merged by Linus
and should be in the Linux 4.14 release. To request hugetlbfs
support a new memfd_create() flag (MFD_HUGETLB) was added.
This patch documents the following commit:
commit 749df87bd7bee5a79cef073f5d032ddb2b211de8
Author: Mike Kravetz <mike.kravetz@oracle.com>
Date: Wed Sep 6 16:24:16 2017 -0700
mm/shmem: add hugetlbfs support to memfd_create()
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Explain the older behavior, and why it changed. This is a
follow-up to Mike Kravetz's patch documenting the behavior
for old_size==0 with shared mappings.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since at least the 2.6 time frame, mremap() would create a new
mapping of the same pages if 'old_size == 0'. It would also leave
the original mapping. This was used to create a 'duplicate
mapping'.
A recent change was made to mremap() so that an attempt to create a
duplicate a private mapping will fail.
Document the 'old_size == 0' behavior and new return code from
below commit.
commit dba58d3b8c5045ad89c1c95d33d01451e3964db7
Author: Mike Kravetz <mike.kravetz@oracle.com>
Date: Wed Sep 6 16:20:55 2017 -0700
mm/mremap: fail map duplication attempts for private mappings
v2: Fix incorrect wording noticed by Jann Horn.
Remove deprecated and memfd_create() discussion as
suggested by Florian Weimer.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Reviewed-by: Jann Horn <jannh@google.com>
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add MADV_WIPEONFORK and MADV_KEEPONFORK documentation,
which has been merged for the 4.14 kernel.
While documenting what EINVAL means for MADV_WIPEONFORK,
I realized that MADV_FREE has the same thing going on,
so I documented EINVAL for both in the ERRORS section.
This patch documents the following kernel commit:
commit d2cd9ede6e193dd7d88b6d27399e96229a551b19
Author: Rik van Riel <riel@redhat.com>
Date: Wed Sep 6 16:25:15 2017 -0700
mm,fork: introduce MADV_WIPEONFORK
Signed-off-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Colm MacCárthaigh <colm@allcosts.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The existing example given specifically states that it focus on
x86 (TSO memory model), but gives a read-read vs write-write
ordering example, even though this scenario does not require
explicit barriers on TSO.
So either we change the example architecture to a weakly-ordered
architecture, or we change the example to a scenario requiring
barriers on x86.
Let's stay on x86, but provide a Dekker as example instead.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
CC: Michael Kerrisk <mtk.manpages@gmail.com>
CC: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Link: https://stackoverflow.com/questions/45970525/is-the-example-in-the-membarrier-man-page-pointless-in-x86
Link: https://lwn.net/Articles/573436/
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Note one of the significant advantages of O_PATH: many of the
operations applied to O_PATH file descriptors don't require
read permission, so there's no readon why the open() itself
should require read permission.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In the discussion of O_PATH, make it completely obvious that
fchdir() file descriptor must refer to a directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Oliver Ebert