Document the FICLONE and FICLONERANGE ioctls, formerly known as
the BTRFS_IOC_CLONE and BTRFS_IOC_CLONE_RANGE ioctls.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
iBoth add_key and the utility "keyctl add" return EINVAL when
attempting to add a user key with an empty or NULL payload.
The manpage implies that this should be valid.
From my reading of the kernel source, this has not been possible
since at least linux kernel commit 1da177e4 (2.6.12-rc2 on
2005-04-16).
Until kernel commit cf7f601c,
security/keys/user_defined.c:user_instantiate returned -EINVAL
if datalen <= 0. That commit only moved this behavior to a new
user_preparse function, where it remains today in b562e44f
(4.5.0 on 2016-03-13).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Update the description of the MTMKPART operation of MTIOCTOP to match
the changes in kernel version 4.6 (commit
8038e6456a3e6f5c4759e0d73c4f9165b90c93e7)
Signed-off-by: Kai Mäkisara <kai.makisara@kolumbus.fi>
Fix the description of read() in variable block mode if the next
block is larger than the requested byte count: error is returned
(as already documented with ENOMEM; better to complete the change
later than never ?-)
Signed-off-by: Kai Mäkisara <kai.makisara@kolumbus.fi>
The existing text makes no differentiation between different
"classes" of mount flags. However, certain flags such as
MS_REMOUNT, MS_BIND, MS_MOVE, etc. determine the general
type of operation that mount() performs. Furthermore, the
choice of which class of operation to perform is performed in
a certain order, and that order is significant if multiple
flags are specified. Restructure and extend the text to
reflect these details.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Removed text referring to text not being helpful to users. Provide
the error text instead to allow the reader to determine whether it
is helpful. Recommend against using NDEBUG for programs to
exhibit deterministic behavior. Moved description ahead of
recommendations.
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
This error appears to have been injected into glibc
when copying some headers from BSD.
See https://bugs.debian.org/825548
Reported-by: Jacob Willoughby <jacob@spacemonkey.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Hi Michael,
0f9e647 removed the obsolete console(4) page but we still have few
references to it. The patch below removes them or converts to refs
to concole_ioctl(4) where appropriate.
Quoting Ori:
The manpage for strncasecmp has a few wording issues that can be improved:
1)
In the DESCRIPTION section, "except it compares only the first n
bytes of s1"
s1 can be shorter than n bytes. Consider adding "(at most)" after
"first".
For comparison with reference materials, POSIX uses the wording
"not more than n bytes", OSX and FreeBSD use "compares at
most [...]".
2)
In the RETURN VALUE section: "if s1 (or the first n bytes
thereof) is found [...] to match [...] s2"
This could theoretically be read to suggest that the first n bytes
of s1 are compared against the FULL s2, which is not the case.
Consider removing the parenthetical altogether (thus, not
mentioning 'n' at all). POSIX doesn't mention 'n' in its RETURN
VALUE section.
3)
The RETURN VALUE section doesn't mention case insensitivity. It's
in the DESCRIPTION, but perhaps it should also be in this section.
POSIX mentions case-insensitivity in RETURN VALUE.
Consider adding "and ignoring case" after "respectively".
Reported-by: Ori Avtalion <ori@avtalion.name>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Quoting Tom:
The statement "With a zero flags argument, recv() is equivalent to
read(2)." is not correct. In the case of passing a UDP socket an
empty buffer the two calls differ. read(2) will be a noop (as it
rightly says in its manpage), but recv(2) will discard the
packet.
We ran into this in networkd, as we use FIONREAD to determine the
buffer size (and allocate the right buffer), so in case someone
passed us an empty packet we would end up in a busy loop when we
were using read(2). Changing to recv(2) fixed the issue
[https://github.com/systemd/systemd/pull/3299].
Reported-by: Tom Gundersen <teg@jklm.no>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The lirc.h header has landed in the kernel, and the kernel docs
has been updated all of which reflected in this patch.
Here is still an open issue with duplicated info in the kernel
docs and the manpage. Eventually, this should be addressed but
I frankly don't know how. In the meantime, acknowledge the fact
that the kernel docs is the ultimate source
Darrick J. Wong