The intended text was hidden elsewhere in the source of the
page as a comment.
https://bugzilla.kernel.org/show_bug.cgi?id=201029
Reported-by: Mike Weilgart <mike.weilgart@verticalsysadmin.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In particular, it is possible to write "threaded" to a
cgroup.type file if the current type is "domain threaded".
Previously, the text had implied that this was not possible.
Verified by experiment on Linux 4.15 and 4.19-rc.
Reported-by: Leah Hanson <lhanson@pivotal.io>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After clone(CLONE_NEWPID), /proc/PID/ns/pid_for_children is empty
until the first child is created. Verified by experiment.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
There is not an acceptable reason to use these functions ever in
new code. For example, just observe the implementation of the
KDF:
/*
* Turn password into DES key
*/
void
passwd2des_internal (char *pw, char *key)
{
int i;
memset (key, 0, 8);
for (i = 0; *pw && i < 8; ++i)
key[i] ^= *pw++ << 1;
des_setparity (key);
}
This kind of nonsense isn't okay in the year 2017. Therefore, we
enlighten our poor users.
[Note from mtk: I think Jason knows that of which he talks.]
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The kernel doesn't allow unsharing a pid NS if it has previously been
unshared, per this check in copy_pid_ns:
if (task_active_pid_ns(current) != old_ns)
return ERR_PTR(-EINVAL);
so let's note that.
Signed-off-by: Tycho Andersen <tycho@tycho.ws>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The number of bytes that can be written to the pipe may be less
(sometimes substantially less) than the nominal capacity. This
was confirmed with some testing. For example, when writing
4097-byte blocks to a pipe with 65536 byte capacity, only 45066
bytes could be written (i.e., 20470 bytes less than 65536).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The discussion is phrased in terms of signals send using kill(2),
but applies equally to a signal sent by the kernel.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The memfd_create function and its corresponding constants have
required _GNU_SOURCE for as long as they've been in glibc.
Signed-off-by: Joseph C. Sible <josephcsible@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
There's a detailed explanation in glob(7), so reuse the same text
glob(3) uses to redirect the reader, rather than inlining a short
explanation.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
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>
I regularly see excessive fd usage bugs (or even leaks) caused by
people who think they need to keep the fd open as long as the
mapping exists.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
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>
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>
MINSTKSZ is not defined anywhere, MINSIGSTKSZ seems valid instead.
Signed-off-by: Hiroya Ito <hiroyan@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk