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>
In Linux 4.14, the action component of the return value
switched from being 15 bits to being 16 bits. A new macro,
SECCOMP_RET_ACTION_FULL, that masks the 16 bits was added,
to replace the older SECCOMP_RET_ACTION.
Reported-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Linux 4.14 added SECCOMP_RET_KILL_THREAD as a synonym for
SECCOMP_RET_KILL. Remove also the discussion of multithreaded
processes, since that will be addressed in the documentation
of SECCOMP_RET_KILL_PROCESS.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
vfork(2), getpid(2) and others which return pid_t already do this.
mtk: Additional info from Ahmad: <unistd.h> defines 'pid_t',
but only dependent on certain FTMs beng defined.
Cc: linux-man@vger.kernel.org
Signed-off-by: Ahmad Fatoum <ahmad@a3f.at>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Based on an email discussion with Florian Weimer and
Adhemerval Zanella on the libc-alpha mailing list.
("Seccomp implications for glibc wrapper function changes",
7 Nov 2017).
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Document the seccomp /proc interfaces in Linux 4.14:
/proc/sys/kernel/seccomp/actions_avail and
/proc/sys/kernel/seccomp/actions_logged.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Point the reader at strace(1) as a way of discovering system calls
that might need to be filtered.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
From a conversation with Walter Harms:
> i am confused, i understand that:
> ss.ss_sp = malloc(SIGSTKSZ);
>
> ss.ss_size = SIGSTKSZ;
> ss.ss_flags = 0;
> if (sigaltstack(&ss, NULL) == -1)
>
> is equivalent to:
> ss.ss_sp = malloc(SIGSTKSZ);
>
> ss.ss_size = SIGSTKSZ;
> ss.ss_flags = SS_ONSTACK ;
> if (sigaltstack(&ss, NULL) == -1)
>
> but also to
> ss.ss_sp = malloc(SIGSTKSZ);
>
> ss.ss_size = SIGSTKSZ;
> ss.ss_flags = SS_ONSTACK | SOMETHING_FLAG ;
> if (sigaltstack(&ss, NULL) == -1)
>
> so the use of SS_ONSTACK would result in ss.ss_flags = 0 no matter what.
> OR
> SS_ONSTACK is a no-op in Linux
I see what you mean. The point is back then that SS_ONSTACK was
the only flag that could (on Linux) be specified in ss.ss_flags,
so that "SS_ONSTACK | SOMETHING_FLAG" was a nonexistent case.
These days, it's possible to specify the new SS_AUTODISARM
flag in ss.ss_flags, which I think is why you are doubtful
about the new page text.
Reported-by: Walter Harms <wharms@bfs.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[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>
Michael Kerrisk