connect.2: Document error semantics of nonblocking UNIX domain sockets
connect(2) on a nonblocking UNIX domain socket when the receive
queue is full results in EAGAIN [1]. This is unlike other
connection-based socket families that return EINPROGRESS as
already documented.
mtk: confirmed with some light testing. And in
net/unix/af_unix.c::unix_stream_connect(), we have:
if (unix_recvq_full(other)) {
err = -EAGAIN;
if (!timeo)
goto out_unlock;
Signed-off-by: Benjamin Peterson <benjamin@python.org> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Joseph Sible [Thu, 9 Aug 2018 04:23:13 +0000 (00:23 -0400)]
pivot_root.2: Document EINVAL if root is rootfs
Per the comment on the pivot_root syscall in fs/namespace.c:
Also, the current root cannot be on the 'rootfs'
(initial ramfs) filesystem. See
Documentation/filesystems/ramfs-rootfs-initramfs.txt
for alternatives in this situation.
Signed-off-by: Joseph C. Sible <josephcsible@gmail.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Sun, 26 Aug 2018 08:38:09 +0000 (10:38 +0200)]
trunc.3: Make the description a little clearer
The double negative is a little confusing, but required. But try
to make the semantics a little clearer in the wording (which is
now closer to the wording in the C standard).
Reported-by: Eric Benton <erbenton@comcast.net> Reported-by: G. Branden Robinson <g.branden.robinson@gmail.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Mon, 20 Aug 2018 13:58:55 +0000 (15:58 +0200)]
mount.2: MS_SILENT is ignored when changing propagation type
MS_SILENT can be specified when changing propagation type,
but is ignored, as far as I can see from reading the code.
(The flags are passed to do_change_type(), which, as well
as the propagation flags, allows MS_REC and MS_SILENT
(in flags_to_propagation_type()), but does noting with
MS_SILENT. (Linux 4.17 source)
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Extended information for timerfd file descriptors in
/proc/[pid]/fdinfo was added in commit af9c4957cf21 ("timerfd:
Implement show_fdinfo method", 2014-07-16), to support
checkpoint/restore for such file descriptors (see also the
TFD_IOC_SET_TICKS ioctl which is documented in timerfd_create.2).
Signed-off-by: Lucas Werkmeister <mail@lucaswerkmeister.de> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Pathname escaping is not done properly in /proc/<pid>/maps;
because of this, different pathnames may appear the same
(verified by experiment and reading the source code).
Further details from Elvira about the relevant location in
the kernel code:
show_map_vma() from fs/proc/task_mmu.c uses seq_file_path()
from fs/seq_file.c to print the dentry name, which in turn
calls seq_path() from the same file. seq_path() uses
d_path() from fs/d_path.c to get the path name; this is
where the " (deleted)" part comes from. This is followed by
mangling the string with mangle_path() (fs/seq_file.c); this
function only replaces those characters that were supplied
in the "esc" argument and does not bother with escaping
anything else ('\\', for example). The value of this
argument comes without modifications from the initial call
of seq_file_path() by show_map_vma(), and that is "\n".
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Vince Weaver [Mon, 13 Aug 2018 14:04:06 +0000 (16:04 +0200)]
perf_event_open.2: Document the PERF_EVENT_IOC_PAUSE_OUTPUT ioctl
The PERF_EVENT_IOC_PAUSE_OUTPUT ioctl was introduced in Linux 4.7.
I've have this patch for a long time, I apologize for the delay
in getting it submitted. I've made some minor changes to the
original patch proposed by Wang Nan.
Signed-off-by: Wang Nan <wangnan0@huawei.com> Reviewed-by: Vince Weaver <vincent.weaver@maine.edu> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Vince Weaver [Tue, 12 Jun 2018 16:12:31 +0000 (12:12 -0400)]
perf_event_open.2: Clarify exclude_idle
It turns out no one is really sure what the perf_event_open.2
exclude_idle field is supposed to do, and a recent thread on the
linux-kernel list:
[RFC] perf/core: what is exclude_idle supposed to do
did not really clarify things.
I think the following adjustment to the page clarifies things
at least a little.
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Vince Weaver [Mon, 11 Jun 2018 17:26:52 +0000 (13:26 -0400)]
perf_event_open.2: Fix prctl behavior description
Some discussion on the linux-perf-users list has turned up that
the perf_event_open.2 description of how
PR_TASK_PERF_EVENTS_ENABLE / PR_TASK_PERF_EVENTS_DISABLE prctl()
works is misleading.
The descriptions were based on the tools/perf/design.txt document
which describes behavior that was removed in 082ff5a2767a06 (prior
to 2.6.31, the first release with perf_event_open support).
I have written some tests in my perf_event_tests testsuite that
verifies the behavior of prctl() in this case.
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Keno Fischer [Fri, 3 Aug 2018 00:07:14 +0000 (20:07 -0400)]
proc.5: Correct description of NStgid
The left-most pid namespace in a given procfs' `NStgid` does not
change based on the pid namespace of the reading process. Rather,
each procfs has an associated outer-most namespace, which gets
set when the procfs is mounted:
i.e. either the root namespace for kernel mounts or the namespace
of the mounting process. This ns then gets saved in the fs' super
block and is the basis for most operations. It is this ns that the
left-most value of `NStgid` is relative to, not the reading process.
Reported-by: Robert O'Callahan <robert@ocallahan.org> Signed-off-by: Keno Fischer <keno@juliacomputing.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Sat, 28 Jul 2018 18:44:56 +0000 (20:44 +0200)]
unshare.2: Same EINVAL errors as for clone(2) can also occur with unshare(2)
The EINVAL errors that can occur for clone(2) when it is called
with various CLONE_NEW* flags and the kernel was not configured
with support for the corresponding namespace can also occur for
unshare(2). (As far as I can see, these errors don't occur for
either clone(2) or unshare(2) when it comes to CLONE_NEWNS and
CLONE_NEWCGROUP.)
Reported-by: Shawn Landden <shawn@git.icu> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
projects / thirdparty / man-pages.git / log
