Adrian Bunk [Sat, 25 Nov 2017 10:12:07 +0000 (12:12 +0200)]
makedev.3: glibc has deprecated exposing the definitions via <sys/types.h>
Compile warning with glibc 2.25:
warning: In the GNU C Library, "makedev" is defined by
<sys/sysmacros.h>. For historical compatibility, it is
currently defined by <sys/types.h> as well, but we plan to
remove this soon. To use "makedev", include <sys/sysmacros.h>
directly. If you did not intend to use a system-defined macro
"makedev", you should undefine it after including
<sys/types.h>.
Michael Kerrisk [Thu, 23 Nov 2017 09:25:45 +0000 (10:25 +0100)]
errno.3: Recast the advice against manually declaring 'errno'
Recast the advice against manually declaring 'errno' to
a more modern perspective. It's 13 years since the original
text was added, and even then it was describing old behavior.
Cast the description to be about behavior further away in
time, and note more clearly that manual declaration will
cause problems with modern C libraries.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
NeilBrown [Tue, 21 Nov 2017 21:15:13 +0000 (08:15 +1100)]
open_by_handle_at.2: Clarifications needed due to NFS reexport
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 (?).
Michael Kerrisk [Mon, 20 Nov 2017 11:13:25 +0000 (12:13 +0100)]
socket.7: Correct the description of SO_RXQ_OVFL
Two reports that the description of SO_RXQ_OVFL was wrong.
======
Commentary from Tobias:
This bug pertains to the manpage as visible on man7.org right
now.
The socket(7) man page has this paragraph:
SO_RXQ_OVFL (since Linux 2.6.33)
Indicates that an unsigned 32-bit value ancillary
message (cmsg) should be attached to received skbs
indicating the number of packets dropped by the
socket between the last received packet and this
received packet.
The second half is wrong: the counter (internally,
SOCK_SKB_CB(skb)->dropcount is *not* reset after every packet.
That is, it is a proper counter, not a gauge, in monitoring
parlance.
A better version of that paragraph:
SO_RXQ_OVFL (since Linux 2.6.33)
Indicates that an unsigned 32-bit value ancillary
message (cmsg) should be attached to received skbs
indicating the number of packets dropped by the
socket since its creation.
======
Commentary from Petr
Generic SO_RXQ_OVFL helpers sock_skb_set_dropcount() and
sock_recv_drops() implements returning of sk->sk_drops (the total
number of dropped packets), although the documentation says the
number of dropped packets since the last received one should be
returned (quoting the current socket.7):
SO_RXQ_OVFL (since Linux 2.6.33)
Indicates that an unsigned 32-bit value ancillary message (cmsg)
should be attached to received skbs indicating the number of packets
dropped by the socket between the last received packet and this
received packet.
I assume the documentation needs to be updated, as fixing this in
the code could break programs depending on the current behavior,
although the formerly planned functionality seems to be more
useful.
The problem can be revealed with the following program:
int extract_drop(struct msghdr *msg)
{
struct cmsghdr *cmsg;
int rtn;
// Kernel doubles this limit, but it accounts also the SKB overhead,
// but it receives as long as there is at least 1 byte free.
i = sizeof msg;
setsockopt(sk1, SOL_SOCKET, SO_RCVBUF, &i, sizeof i);
setsockopt(sk1, SOL_SOCKET, SO_RXQ_OVFL, &one, sizeof one);
which prints
rtn: 49152 drop -1
rtn: 49152 drop -1
rtn: -1
rtn: 49152 drop 1
rtn: 49152 drop 1
rtn: -1
rtn: 49152 drop 2
rtn: 49152 drop 2
rtn: -1
rtn: 49152 drop 3
rtn: 49152 drop 3
rtn: -1
although it should print (according to the documentation):
rtn: 49152 drop 0
rtn: 49152 drop 0
rtn: -1
rtn: 49152 drop 1
rtn: 49152 drop 0
rtn: -1
rtn: 49152 drop 1
rtn: 49152 drop 0
rtn: -1
rtn: 49152 drop 1
rtn: 49152 drop 0
rtn: -1
Reported-by: Petr Malat <oss@malat.biz> Reported-by: Tobias Klausmann <klausman@schwarzvogel.de> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Breno Leitao [Tue, 7 Nov 2017 12:23:15 +0000 (10:23 -0200)]
pkey_alloc.2: Fix argument order
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>
Michael Kerrisk [Mon, 20 Nov 2017 08:59:43 +0000 (09:59 +0100)]
proc.5: Rework the description of /proc/PID/mountinfo parent-ID field
After comments from Miklos, and further digging in the kernel
source that showed that chroot() can also result in "hidden"
parent-IDs in mountinfo, I've revised the description of
mountinfo.
In fs/proc_namespace.cs::how_mountinfo() there is:
/* mountpoints outside of chroot jail will give SEQ_SKIP on this */
err = seq_path_root(m, &mnt_path, &p->root, " \t\n\\");
if (err)
goto out;
I instrumented the 'if (err)' code path with printk()
to show that there is indeed a record corresponding to the
parent-ID for the process root that is being skipped.
Michael Kerrisk [Sun, 12 Nov 2017 15:55:35 +0000 (16:55 +0100)]
proc.5: Correct the description of the parent mount ID for /proc/PID/mountinfo
I do not have an exact handle on the details, but I can see
roughly what is going on. Internally, there seems to be one
("hidden") mount ID reserved to each mount namespace, and that ID
is the parent of the root mount point.
Looking through the (4.14) kernel source, mount IDs are allocated
by a kernel function called mnt_alloc_id() (in fs/namespace.c),
which is in turn called by alloc_vfsmnt() which is in turn called
by clone_mnt().
A new mount namespace is created by the kernel function
copy_mnt_ns() (in fs/namespace.c, called by
create_new_namespaces() in kernel/nsproxy.c). The copy_mnt_ns()
function calls copy_tree() (in fs/namespace.c), and copy_tree()
calls clone_mnt() in *two* places. The first of these is the call
that creates the "hidden" mount ID that becomes the parent of the
root mount point. (I verified this by instrumenting the kernel
with a few printk() calls to display the IDs.) The second place
where copy_tree() calls clone_mnt() is in a loop that replicates
each of the mount points (including the root mount point) in the
source mount namespace.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since Linux 4.15 the number of idmap lines has been bumped to 340.
The patch also removes the "(arbitrary)" in "There is an
(arbitrary) limit on the number of lines in the file." since the
340 line limit is well-explained by the current implementation.
The struct recording the idmaps is 12 bytes and quite some proc
files only allow writes the size of a single page size which is
4096kB. This leaves room for 340 idmappings (340 * 12 = 4080
bytes). The struct layout itself has been chosen very carefully
to allow for an implementation that limits the time-complexity for
the idmap codepaths to O(log n). However, I think it's unnecessary
to expose this much implementation detail to users in the man
page. So only mention this in the commit message. Furthermore,
the comment about the page size restriction is misleading. The
kernel sources show that >= page size is considered an error.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Sat, 18 Nov 2017 22:13:44 +0000 (23:13 +0100)]
seccomp.2: Change SECCOMP_RET_ACTION to SECCOMP_RET_ACTION_FULL
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>
Michael Kerrisk [Sat, 18 Nov 2017 18:00:32 +0000 (19:00 +0100)]
seccomp.2: Add SECCOMP_RET_KILL_THREAD description and rework SECCOMP_RET_KILL text
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>
projects / thirdparty / man-pages.git / log
