This nr_segs==0 case is no-op; the call succeeds and no
EINVAL error is returned.
See fs/splice.c vmsplice syscall which contains:
if (unlikely(nr_segs > UIO_MAXIOV))
return -EINVAL;
else if (unlikely(!nr_segs))
return 0;
And looking at the git log suggests that the code was always thus.
Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The text "Each of these calls sets errno to an appropriate
value in the case of an error." is not only for waitid.
This patch adds a paragraph break to move the errno note
to a new paragraph where it makes sense, as it applies to
all the wait* functions.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The default values of SHMALL and SHMMAX have been increased.
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
See https://bugzilla.kernel.org/show_bug.cgi?id=84701
As noted by C. Alex North-Keys:
1) Command name extensions considered harmful: Adding ".sh", or
any other unneeded extension, unnecessarily duplicates meta
information already present in the interpreter directive,
exposing an implementation detail that then ends up explicitly
part of other programs running this one. Later, when such a
script is replaced with a new version in Python, C, etc., the
useless ".sh" has to be retained to avoid breaking those other
programs' calls to this one, and now has a stark antifunction
of lying about the script's content and occasionally causing
admins to run undefined experiments as root (like
"bash -x ./reallyperlscript.sh"). Such extensions, while fine
in DOS which ignores extensions explicitly, is a serious flaw
in Unix-targeted script writing. Canonical documentation
from the Linux manual should not support such a flawed idiom -
recommending against it would be preferred.
A more extensive rant against them can be found at:
http://www.talisman.org/~erlkonig/documents/commandname-extensions-considered-harmful
2) The space after "#!" in the interpreter directive is minor -
and the kernel's fs/binfmt_script.c specifically allows for it -
but versions of unix have length limits from ~30 characters to
Linux's 127 or so (if that number's correct) so the space does
have a cost. Most scripts I've seen lack that space, and
there's no real reason to encourage it.
Reported-by: C. Alex North-Keys <erlkonig@talisman.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Quoting Eric Biederman:
One thing that has come up recently (in 3 separate
implementations) is that mount(MS_REMOUNT|...,...) must include
all of the mount flags that need to be preserved. People
creating read-only bind mounts tend to miss that and the locked
flags in mount namespaces. That issue was flushed out now that
the kernel is now not allowing most mount flags to be cleared in
mount namespaces. The interface is non-intuitive and we should
at least document the weirdness.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>