MAP_FIXED has been widely used for a very long time, yet the man
page still claims that "the use of this option is discouraged".
The documentation assumes that "less portable" == "must be discouraged".
Instead of discouraging something that is so useful and widely used,
change the documentation to explain its limitations better.
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It makes no sense to describe this flag in two different
manual pages, so consolidate the description to one page.
Furthermore, the following statement that was in the prctl(2)
page is not correct:
A thread's effective capability set is always cleared
when such a credential change is made, regardless of
the setting of the "keep capabilities" flag.
The effective set is not cleared if, for example, the
credential sets were [ruid != 0, euid != 0, suid == 0]
and suid is switched to zero while the "keep capabilities"
flag is set.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As hinted in the kernel source, MAX_HANDLE_SZ is a hint
rather than a promise:
/* limit the handle size to NFSv4 handle size now */
#define MAX_HANDLE_SZ 128
Note the "now" (probably should be "for now").
So change the description to make this clear.
Reported-by: Lennart Poettering <lennart@poettering.net>
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The recent addition of NFS re-export and the possibility of using
name_to_handle_at() on an NFS filesystem raises issues with
name_to_handle_at() which have not been properly documented.
Getting the file handle for an untriggered automount point is
arguably meaningless and in certainly not supported by NFS.
name_to_handle_at() will return -EOVERFLOW even though the
requested "handle_bytes" is large enough. This is an unfortunate
overloading of the error code, but is manageable.
So clarify this and also note that the mount_id is returned when
EOVERFLOW is reported.
Thought: it would be nice if mount_id were returned in the
EOPNOTSUPP case too. I guess it is too late to fix that (?).
Link: https://github.com/systemd/systemd/issues/7082
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add more information about the iocb structure. It explains the
fields of the I/O control block structure which is passed to the
io_submit call.
The work also includes the nowait feature flags which is currently
posted at http://marc.info/?l=linux-fsdevel&m=149664103900715&w=2
Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Currently pkey_alloc() syscall has two arguments, and the very
first argument is still not supported as in kernel 4.14-rc8 and
should be set to zero, as showed in the following syscall
implementation:
SYSCALL_DEFINE2(pkey_alloc, unsigned long, flags, ...)
{
int pkey;
int ret;
/* No flags supported yet. */
if (flags)
return -EINVAL;
This behaviour is also documented correctly in the kernel
documentation as Documentation/x86/protection-keys.txt
The second argument is the one that should specify the page
access rights.
This patch fixes the manpage to describe how the code behaves.
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add documentation for those new membarrier() commands:
MEMBARRIER_CMD_PRIVATE_EXPEDITED
MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED
Adapt the MEMBARRIER_CMD_SHARED return value documentation to reflect
that it now returns -EINVAL when issued on a system configured for
nohz_full.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
CC: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
CC: Peter Zijlstra <peterz@infradead.org>
CC: Paul Turner <pjt@google.com>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Andrew Hunter <ahh@google.com>
CC: Andy Lutomirski <luto@amacapital.net>
CC: Andi Kleen <andi@firstfloor.org>
CC: Dave Watson <davejwatson@fb.com>
CC: Chris Lameter <cl@linux.com>
CC: Ingo Molnar <mingo@redhat.com>
CC: "H. Peter Anvin" <hpa@zytor.com>
CC: Ben Maurer <bmaurer@fb.com>
CC: Steven Rostedt <rostedt@goodmis.org>
CC: Josh Triplett <josh@joshtriplett.org>
CC: Linus Torvalds <torvalds@linux-foundation.org>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Russell King <linux@arm.linux.org.uk>
CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Will Deacon <will.deacon@arm.com>
CC: Michael Kerrisk <mtk.manpages@gmail.com>
CC: Boqun Feng <boqun.feng@gmail.com>
CC: linux-api@vger.kernel.org
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The kernel defaults to either SECCOMP_RET_KILL_PROCESS
or SECCOMP_RET_KILL_THREAD for unrecognized filter
return action values.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
From linux/v4.14-rc6/source/net/ipv4/tcp.c:
if (tp->fastopen_req)
return -EALREADY; /* Another Fast Open is in progress */
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk